Klassen:~django.test.RequestFactory delar samma API som testklienten. Men istället för att bete sig som en webbläsare ger RequestFactory ett sätt att generera en begärandeinstans som kan användas som det första argumentet för alla vyer. Detta innebär att du kan testa en vyfunktion på samma sätt som du skulle testa vilken annan funktion som helst - som en svart låda, med exakt kända ingångar, och testa för specifika utgångar.
\nAPI:et för RequestFactory är en något begränsad delmängd av testklientens API:
It only has access to the HTTP methods get(),\npost(), put(),\ndelete(), head(),\noptions(), and trace().
Dessa metoder accepterar alla samma argument undantaget för follow. Eftersom detta bara är en fabrik för att producera förfrågningar är det upp till dig att hantera svaret.
Den stöder inte middleware. Sessions- och autentiseringsattribut måste tillhandahållas av testet självt om det krävs för att vyn ska fungera korrekt.
Följande är ett enhetstest som använder request factory:
\nfrom django.contrib.auth.models import AnonymousUser, User\nfrom django.test import RequestFactory, TestCase\n\nfrom .views import MyView, my_view\n\n\nclass SimpleTest(TestCase):\n def setUp(self):\n # Every test needs access to the request factory.\n self.factory = RequestFactory()\n self.user = User.objects.create_user(\n username="jacob", email="jacob@…", password="top_secret"\n )\n\n def test_details(self):\n # Create an instance of a GET request.\n request = self.factory.get("/customer/details")\n\n # Recall that middleware are not supported. You can simulate a\n # logged-in user by setting request.user manually.\n request.user = self.user\n\n # Or you can simulate an anonymous user by setting request.user to\n # an AnonymousUser instance.\n request.user = AnonymousUser()\n\n # Test my_view() as if it were deployed at /customer/details\n response = my_view(request)\n # Use this syntax for class-based views.\n response = MyView.as_view()(request)\n self.assertEqual(response.status_code, 200)\nRequestFactory skapar WSGI-liknande förfrågningar. Om du vill skapa ASGI-liknande förfrågningar, inklusive att ha ett korrekt ASGI scope, kan du istället använda django.test.AsyncRequestFactory.
Den här klassen är direkt API-kompatibel med RequestFactory, med den enda skillnaden att den returnerar ASGIRequest-instanser i stället för WSGIRequest-instanser. Alla dess metoder är fortfarande synkrona callables.
Godtyckliga nyckelordsargument i defaults läggs till direkt i ASGI-omfånget.
För att kunna testa klassbaserade vyer utanför request/response-cykeln måste du se till att de är korrekt konfigurerade genom att anropa setup() efter instantiering.
Anta till exempel följande klassbaserade vy:
\nVyer.pyfrom django.views.generic import TemplateView\n\n\nclass HomeView(TemplateView):\n template_name = "myapp/home.html"\n\n def get_context_data(self, **kwargs):\n kwargs["environment"] = "Production"\n return super().get_context_data(**kwargs)\nDu kan testa metoden get_context_data() direkt genom att först instansiera vyn och sedan skicka en request till setup(), innan du fortsätter med testkoden:
tests.pyfrom django.test import RequestFactory, TestCase\nfrom .views import HomeView\n\n\nclass HomePageTest(TestCase):\n def test_environment_set_in_context(self):\n request = RequestFactory().get("/")\n view = HomeView()\n view.setup(request)\n\n context = view.get_context_data()\n self.assertIn("environment", context)\nInställningen ALLOWED_HOSTS valideras när tester körs. Detta gör att testklienten kan skilja mellan interna och externa webbadresser.
Projekt som stöder multitenancy eller på annat sätt ändrar affärslogik baserat på begärans värd och använder anpassade värdnamn i tester måste inkludera dessa värdar i ALLOWED_HOSTS.
Det första alternativet är att lägga till värdarna i din inställningsfil. Till exempel innehåller testsviten för docs.djangoproject.com följande:
\nfrom django.test import TestCase\n\n\nclass SearchFormTestCase(TestCase):\n def test_empty_get(self):\n response = self.client.get(\n "/en/dev/search/",\n headers={"host": "docs.djangoproject.dev:8000"},\n )\n self.assertEqual(response.status_code, 200)\noch inställningsfilen innehåller en lista över de domäner som stöds av projektet:
\nALLOWED_HOSTS = ["www.djangoproject.dev", "docs.djangoproject.dev", ...]\nAnother option is to add the required hosts to ALLOWED_HOSTS using\noverride_settings() or\nmodify_settings. This option may be\npreferable in standalone apps that can’t package their own settings file or\nfor projects where the list of domains is not static (e.g., subdomains for\nmultitenancy). For example, you could write a test for the domain\nhttp://otherserver/ as follows:
from django.test import TestCase, override_settings\n\n\nclass MultiDomainTestCase(TestCase):\n @override_settings(ALLOWED_HOSTS=["otherserver"])\n def test_other_domain(self):\n response = self.client.get("http://otherserver/foo/bar/")\nOm du avaktiverar ALLOWED_HOSTS-kontrollen (ALLOWED_HOSTS = ['*']) när du kör tester förhindrar du att testklienten ger ett användbart felmeddelande om du följer en omdirigering till en extern URL.
Om du testar en konfiguration med flera databaser med replikering av primär/replika (kallas master/slave av vissa databaser), utgör denna strategi för att skapa testdatabaser ett problem. När testdatabaserna skapas kommer det inte att finnas någon replikering, och som ett resultat kommer data som skapats på den primära inte att ses på repliken.
\nFör att kompensera för detta tillåter Django dig att definiera att en databas är en testspegel. Tänk på följande (förenklade) exempel på databaskonfiguration:
\nDATABASES = {\n "default": {\n "ENGINE": "django.db.backends.mysql",\n "NAME": "myproject",\n "HOST": "dbprimary",\n # ... plus some other settings\n },\n "replica": {\n "ENGINE": "django.db.backends.mysql",\n "NAME": "myproject",\n "HOST": "dbreplica",\n "TEST": {\n "MIRROR": "default",\n },\n # ... plus some other settings\n },\n}\nI den här installationen har vi två databasservrar: dbprimary, som beskrivs av databasaliaset default, och dbreplica som beskrivs av aliaset replica. Som du kanske förväntar dig har dbreplica konfigurerats av databasadministratören som en läskopia av dbprimary, så under normal aktivitet kommer alla skrivningar till default att visas på replica.
Om Django skapade två oberoende testdatabaser skulle detta bryta alla tester som förväntade sig att replikering skulle ske. Databasen replica har dock konfigurerats som en testspegel (med hjälp av testinställningen MIRROR), vilket indikerar att replica under testning bör behandlas som en spegel av default.
När testmiljön är konfigurerad kommer en testversion av replica inte att skapas. Istället kommer anslutningen till replica att omdirigeras så att den pekar på default. Som ett resultat kommer skrivningar till default att visas på replica - men eftersom de faktiskt är samma databas, inte för att det finns datareplikering mellan de två databaserna. Eftersom detta är beroende av transaktioner måste testerna använda TransactionTestCase istället för TestCase.
Som standard kommer Django att anta att alla databaser är beroende av default-databasen och därför alltid skapa default-databasen först. Det finns dock inga garantier för i vilken ordning andra databaser i din testkonfiguration skapas.
Om din databaskonfiguration kräver en viss skapandeordning kan du ange vilka beroenden som finns med hjälp av testinställningen DEPENDENCIES. Tänk på följande (förenklade) exempel på databaskonfiguration:
DATABASES = {\n "default": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": ["diamonds"],\n },\n },\n "diamonds": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": [],\n },\n },\n "clubs": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": ["diamonds"],\n },\n },\n "spades": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": ["diamonds", "hearts"],\n },\n },\n "hearts": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": ["diamonds", "clubs"],\n },\n },\n}\nI den här konfigurationen kommer databasen diamonds att skapas först, eftersom det är det enda databasaliaset utan beroenden. Aliasen default och clubs skapas därefter (även om ordningen för skapandet av detta par inte är garanterad), sedan hearts och slutligen spades.
Om det finns några cirkulära beroenden i DEPENDENCIES-definitionen, kommer ett ImproperlyConfigured-undantag att uppstå.
TransactionTestCaseLink to this heading#Som standard är available_apps inställd på None. Efter varje test anropar Django flush för att återställa databastillståndet. Detta tömmer alla tabeller och sänder ut post_migrate-signalen, som återskapar en innehållstyp och fyra behörigheter för varje modell. Denna operation blir dyr proportionellt mot antalet modeller.
Om du ställer in available_apps till en lista över applikationer instrueras Django att bete sig som om endast modellerna från dessa applikationer var tillgängliga. Beteendet för TransactionTestCase ändras enligt följande:
post_migrate avfyras före varje test för att skapa innehållstyper och behörigheter för varje modell i tillgängliga appar, ifall de saknas.
Efter varje test tömmer Django endast tabeller som motsvarar modeller i tillgängliga appar. På databasnivå kan trunkering dock kaskadera till relaterade modeller i otillgängliga appar. Dessutom post_migrate avfyras inte; det kommer att avfyras av nästa TransactionTestCase, efter att rätt uppsättning applikationer har valts.
Eftersom databasen inte är helt tömd, om ett test skapar instanser av modeller som inte ingår i available_apps, kommer de att läcka och de kan orsaka att orelaterade tester misslyckas. Var försiktig med tester som använder sessioner; standardsessionsmotorn lagrar dem i databasen.
Eftersom post_migrate inte skickas ut efter rensning av databasen, är dess tillstånd efter ett TransactionTestCase inte detsamma som efter ett TestCase: det saknar de rader som skapats av lyssnare till post_migrate. Med tanke på ordningen i vilken tester utförs är detta inte ett problem, förutsatt att antingen alla TransactionTestCase i en given testsvit deklarerar available_apps, eller ingen av dem.
available_apps är obligatoriskt i Djangos egen testsvit.
Om du ställer in reset_sequences = True på ett TransactionTestCase ser du till att sekvenserna alltid återställs innan testet körs:
class TestsThatDependsOnPrimaryKeySequences(TransactionTestCase):\n reset_sequences = True\n\n def test_animal_pk(self):\n lion = Animal.objects.create(name="lion", sound="roar")\n # lion.pk is guaranteed to always be 1\n self.assertEqual(lion.pk, 1)\nUnless you are explicitly testing primary keys sequence numbers, it is\nrecommended that you do not hardcode primary key values in tests.
\nOm du använder reset_sequences = True kommer testet att gå långsammare, eftersom återställningen av primärnyckeln är en relativt dyr databasoperation.
Om du har testklasser som inte kan köras parallellt (t.ex. för att de delar en gemensam resurs) kan du använda django.test.testcases.SerializeMixin för att köra dem sekventiellt. Denna mixin använder ett filsystem lockfile.
Du kan t.ex. använda __file__ för att bestämma att alla testklasser i samma fil som ärver från SerializeMixin ska köras sekventiellt:
import os\n\nfrom django.test import TestCase\nfrom django.test.testcases import SerializeMixin\n\n\nclass ImageTestCaseMixin(SerializeMixin):\n lockfile = __file__\n\n def setUp(self):\n self.filename = os.path.join(temp_storage_dir, "my_file.png")\n self.file = create_file(self.filename)\n\n\nclass RemoveImageTests(ImageTestCaseMixin, TestCase):\n def test_remove_image(self):\n os.remove(self.filename)\n self.assertFalse(os.path.exists(self.filename))\n\n\nclass ResizeImageTests(ImageTestCaseMixin, TestCase):\n def test_resize_image(self):\n resize_image(self.file, (48, 48))\n self.assertEqual(get_image_size(self.file), (48, 48))\nOm du skriver en återanvändbar applikation kanske du vill använda Django test runner för att köra din egen testsvit och därmed dra nytta av Djangos testinfrastruktur.
\nEn vanlig metod är en tests-katalog bredvid applikationskoden, med följande struktur:
\nruntests.py\npolls/\n __init__.py\n models.py\n ...\ntests/\n __init__.py\n models.py\n test_settings.py\n tests.py\nLåt oss ta en titt på några av dessa filer:
\nruntests.py#!/usr/bin/env python\nimport os\nimport sys\n\nimport django\nfrom django.conf import settings\nfrom django.test.utils import get_runner\n\nif __name__ == "__main__":\n os.environ["DJANGO_SETTINGS_MODULE"] = "tests.test_settings"\n django.setup()\n TestRunner = get_runner(settings)\n test_runner = TestRunner()\n failures = test_runner.run_tests(["tests"])\n sys.exit(bool(failures))\nDetta är det skript som du anropar för att köra testsviten. Det ställer in Django-miljön, skapar testdatabasen och kör testerna.
\nFör tydlighetens skull innehåller detta exempel endast det absolut nödvändiga för att använda Djangos testlöpare. Du kanske vill lägga till kommandoradsalternativ för att kontrollera ordrikedom, skicka in specifika testetiketter som ska köras etc.
\ntester/tester_settings.pySECRET_KEY = "fake-key"\nINSTALLED_APPS = [\n "tests",\n]\nDen här filen innehåller de Django-inställningar som krävs för att köra appens tester.
\nÄven detta är ett minimalt exempel; dina tester kan kräva ytterligare inställningar för att köras.
\nEftersom paketet tests ingår i INSTALLED_APPS när du kör dina tester, kan du definiera modeller som endast gäller tester i dess fil models.py.
Det är uppenbart att unittest inte är det enda testramverket i Python. Även om Django inte ger uttryckligt stöd för alternativa ramverk, ger det ett sätt att anropa tester som är konstruerade för ett alternativt ramverk som om de vore vanliga Django-tester.
När du kör ./manage.py test tittar Django på inställningen TEST_RUNNER för att avgöra vad som ska göras. Som standard pekar TEST_RUNNER på 'django.test.runner.DiscoverRunner'. Den här klassen definierar Djangos standardtestbeteende. Detta beteende innebär:
Utföra global förtestinställning.
Letar efter tester i alla filer under den aktuella katalogen vars namn matchar mönstret test*.py.
Skapa testdatabaserna.
Kör migrate för att installera modeller och initialdata i testdatabaserna.
Kör systemkontroller.
Kör de tester som hittades.
Förstöring av testdatabaserna.
Utföra global nedmontering efter test.
Om du definierar din egen testlöparklass och pekar TEST_RUNNER på den klassen, kommer Django att köra din testlöpare när du kör ./manage.py test. På så sätt är det möjligt att använda valfritt testramverk som kan köras från Python-kod, eller att modifiera Djangos testkörningsprocess för att uppfylla de testkrav du kan ha.
En testlöpare är en klass som definierar en metod run_tests(). Django levereras med en DiscoverRunner-klass som definierar standardtestbeteendet för Django. Denna klass definierar ingångspunkten run_tests(), plus ett urval av andra metoder som används av run_tests() för att ställa in, köra och riva ner testsviten.
DiscoverRunner kommer att söka efter tester i alla filer som matchar mönstret.
top_level kan användas för att ange den katalog som innehåller dina Python-moduler på högsta nivå. Vanligtvis kan Django räkna ut detta automatiskt, så det är inte nödvändigt att ange detta alternativ. Om det anges bör det i allmänhet vara den katalog som innehåller din manage.py-fil.
verbosity bestämmer hur mycket meddelande- och felsökningsinformation som ska skrivas ut till konsolen; 0 är ingen utdata, 1 är normal utdata och 2 är verbose utdata.
Om interactive är True har testsviten behörighet att be användaren om instruktioner när testsviten körs. Ett exempel på detta beteende är att be om tillstånd att ta bort en befintlig testdatabas. Om interactive är False måste testsviten kunna köras utan någon manuell inblandning.
Om failfast är True kommer testsviten att sluta köras efter att det första testfelet har upptäckts.
Om keepdb är True kommer testsviten att använda den befintliga databasen, eller skapa en om det behövs. Om False kommer en ny databas att skapas och användaren uppmanas att ta bort den befintliga databasen, om en sådan finns.
Om reverse är True kommer testfallen att exekveras i motsatt ordning. Detta kan vara användbart för att felsöka tester som inte är ordentligt isolerade och som har bieffekter. Gruppering efter testklass bevaras när detta alternativ används. Det här alternativet kan användas tillsammans med --shuffle för att vända ordningen för ett visst slumpmässigt frö.
debug_mode anger vad inställningen DEBUG ska vara inställd på innan tester körs.
parallel specifies the number of processes. If parallel is greater\nthan 1, the test suite will run in parallel processes. If there are\nfewer test case classes than configured processes, Django will reduce the\nnumber of processes accordingly. Each process gets its own database. This\noption requires the third-party tblib package to display tracebacks\ncorrectly.
tags kan användas för att ange en uppsättning tags för filtrering av tester. Kan kombineras med exclude_tags.
exclude_tags kan användas för att ange en uppsättning taggar för att utesluta tester. Kan kombineras med tags.
Om debug_sql är True, kommer misslyckade testfall att mata ut SQL-frågor som loggas till django.db.backends logger samt spårningen. Om verbosity är 2, kommer frågor i alla tester att matas ut.
test_name_patterns kan användas för att ange en uppsättning mönster för att filtrera testmetoder och klasser efter deras namn.
Om pdb är True kommer en debugger (pdb eller ipdb) att startas vid varje fel eller misslyckande i testet.
Om buffer är True, kommer utdata från godkända tester att kasseras.
If enable_faulthandler is True, faulthandler will be\nenabled.
Om timing är True visas testtider, inklusive databasinstallation och total körtid.
Om shuffle är ett heltal kommer testfallen att blandas i en slumpmässig ordning före exekvering, med heltalet som slumpmässigt frö. Om shuffle är None kommer fröet att genereras slumpmässigt. I båda fallen kommer fröet att loggas och sättas till self.shuffle_seed innan testerna körs. Detta alternativ kan användas för att hjälpa till att upptäcka tester som inte är ordentligt isolerade. Gruppering efter testklass bevaras när detta alternativ används.
logger can be used to pass a Python Logger object.\nIf provided, the logger will be used to log messages instead of printing to\nthe console. The logger object will respect its logging level rather than\nthe verbosity.
durations will show a list of the N slowest test cases. Setting this\noption to 0 will result in the duration for all tests being shown.
Django kan, från tid till annan, utöka testlöparens möjligheter genom att lägga till nya argument. Deklarationen **kwargs tillåter denna expansion. Om du underklassar DiscoverRunner eller skriver din egen testlöpare, se till att den accepterar **kwargs.
Din testlöpare kan också definiera ytterligare kommandoradsalternativ. Skapa eller åsidosätt en klassmetod add_arguments(cls, parser) och lägg till anpassade argument genom att anropa parser.add_argument() inuti metoden, så att kommandot test kan använda dessa argument.
Den klass som används för att bygga testsviten. Som standard är den inställd på unittest.TestSuite. Detta kan åsidosättas om du vill implementera en annan logik för att samla in tester.
Detta är klassen för den testlöpare på låg nivå som används för att köra de enskilda testerna och formatera resultaten. Som standard är den inställd på unittest.TextTestRunner. Trots den olyckliga likheten i namngivningskonventioner är detta inte samma typ av klass som DiscoverRunner, som täcker en bredare uppsättning ansvarsområden. Du kan åsidosätta detta attribut för att ändra hur tester körs och rapporteras.
Det här är klassen som laddar tester, oavsett om det är från TestCases eller moduler eller på annat sätt, och buntar ihop dem till testsviter som köraren kan köra. Som standard är den inställd på unittest.defaultTestLoader. Du kan åsidosätta detta attribut om dina tester kommer att laddas på ovanliga sätt.
Kör testsviten.
\nmed test_labels kan du ange vilka tester som ska köras och det finns stöd för flera format (se DiscoverRunner.build_suite() för en lista över format som stöds).
Denna metod bör returnera antalet tester som misslyckades.
\nOverride this class method to add custom arguments accepted by the\ntest management command. See\nargparse.ArgumentParser.add_argument() for details about adding\narguments to a parser.
Ställer in testmiljön genom att anropa setup_test_environment() och ställa in DEBUG till self.debug_mode (standard är False).
Konstruerar en testsvit som matchar de testetiketter som anges.
\ntest_labels är en lista med strängar som beskriver de tester som ska köras. En testetikett kan ha en av fyra former:
path.to.test_module.TestCase.test_method – Kör en enda testmetod i en testfallsklass.
path.to.test_module.TestCase – Kör alla testmetoder i ett testfall.
path.to.module – Söker efter och kör alla tester i det angivna Python-paketet eller -modulen.
path/to/directory – Sök efter och kör alla tester under den angivna katalogen.
Om test_labels har värdet None kommer testlöparen att söka efter tester i alla filer under den aktuella katalogen vars namn matchar dess mönster (se ovan).
Returnerar en instans av TestSuite som är redo att köras.
Skapar testdatabaserna genom att anropa setup_databases().
Kör systemkontroller på testets databaser.
Kör testsviten.
\nReturnerar resultatet av körningen av testsviten.
\nReturnerar nyckelordsargumenten för att instansiera DiscoverRunner.test_runner med.
Förstör testdatabaserna och återställer villkoren före testet genom att anropa teardown_databases().
Återställer miljön före testet.
\nBeräknar och returnerar en returkod baserad på en testsvit och resultatet från denna testsvit.
\nOm en logger är inställd, loggas meddelandet på den angivna heltalsnivån för loggning (t.ex. logging.DEBUG, logging.INFO eller logging.WARNING). Annars skrivs meddelandet ut till konsolen, med hänsyn till den aktuella verbosity. Exempelvis skrivs inget meddelande ut om verbosity är 0, INFO och högre skrivs ut om verbosity är minst 1 och DEBUG skrivs ut om den är minst 2. Standardvärdet för level är logging.INFO.
django.test.utilsLink to this heading#För att hjälpa till att skapa din egen testlöpare tillhandahåller Django ett antal verktygsmetoder i modulen django.test.utils.
Utför globala inställningar före test, t.ex. installation av instrument för mallrenderingssystemet och konfigurering av dummy-utkorgen för e-post.
\nOm debug inte är None, uppdateras DEBUG-inställningen till dess värde.
Utför global nedmontering efter test, t.ex. avlägsnande av instrument från mallsystemet och återställning av normala e-posttjänster.
\nSkapar testdatabaserna.
\nReturnerar en datastruktur som innehåller tillräckligt med detaljer för att ångra de ändringar som har gjorts. Dessa data kommer att tillhandahållas till teardown_databases()-funktionen när testningen är avslutad.
Argumentet aliases bestämmer vilka DATABASES-alias som testdatabaserna ska konfigureras för. Om det inte anges, är standardvärdet alla DATABASES alias.
Argumentet serialized_aliases bestämmer vilken delmängd av aliases testdatabaser som ska ha sitt tillstånd serialiserat för att möjliggöra användning av funktionen serialized_rollback. Om det inte anges är standardvärdet aliases.
Förstör testdatabaserna och återställer förhållandena före testet.
\nold_config är en datastruktur som definierar de ändringar i databaskonfigurationen som måste återställas. Det är returvärdet för metoden setup_databases().
django.db.connection.creationLink to this heading#Skapandemodulen för databasens backend innehåller också några verktyg som kan vara användbara under testning.
\nSkapar en ny testdatabas och kör migrate mot den.
verbosity har samma beteende som i run_tests().
autoclobber beskriver det beteende som kommer att uppstå om en databas med samma namn som testdatabasen upptäcks:
Om autoclobber är False kommer användaren att bli ombedd att godkänna att den befintliga databasen förstörs. sys.exit anropas om användaren inte godkänner detta.
Om autoclobber är True kommer databasen att förstöras utan att användaren tillfrågas.
keepdb avgör om testkörningen ska använda en befintlig databas eller skapa en ny. Om True används den befintliga databasen, eller skapas om den inte finns. Om False skapas en ny databas och användaren uppmanas att ta bort den befintliga databasen, om en sådan finns.
Returnerar namnet på den testdatabas som skapades.
\ncreate_test_db() har som bieffekt att värdet för NAME i DATABASES ändras så att det motsvarar namnet på testdatabasen.
Förstör databasen vars namn är värdet för NAME i DATABASES och anger värdet för old_database_name i NAME.
Argumentet verbosity har samma beteende som för DiscoverRunner.
Om argumentet keepdb är True kommer anslutningen till databasen att stängas, men databasen kommer inte att förstöras.
Serialiserar databasen till en JSON-sträng i minnet som kan användas för att återställa databastillståndet mellan tester om backend inte stöder transaktioner eller om din svit innehåller testklasser med serialized_rollback=True aktiverat.
\nDenna funktion bör endast anropas när alla testdatabaser har skapats eftersom serialiseringsprocessen kan resultera i frågor mot databaser som inte är testdatabaser beroende på din routingkonfiguration.
\ncoverage.pyLink to this heading#Kodtäckning beskriver hur mycket av källkoden som har testats. Den visar vilka delar av din kod som testas och vilka som inte gör det. Det är en viktig del av testningen av applikationer, så det rekommenderas starkt att du kontrollerar täckningen av dina tester.
\nDjango kan enkelt integreras med coverage.py, ett verktyg för att mäta kodtäckning av Python-program. Först installerar du coverage. Därefter kör du följande från din projektmapp som innehåller manage.py:
coverage run --source='.' manage.py test myapp\nDetta kör dina tester och samlar in täckningsdata för de exekverade filerna i ditt projekt. Du kan se en rapport över dessa data genom att skriva följande kommando:
\ncoverage report\nObservera att en del Django-kod exekverades när testerna kördes, men den listas inte här på grund av flaggan source som skickades till föregående kommando.
För fler alternativ, t.ex. kommenterade HTML-listor med information om missade rader, se dokumenten för coverage.py.
\n