Detta dokument är uppdelat i två huvudavsnitt. Först förklarar vi hur man skriver tester med Django. Sedan förklarar vi hur man kör dem.
\nDjangos enhetstester använder en modul från Pythons standardbibliotek: unittest. Denna modul definierar tester med hjälp av ett klassbaserat tillvägagångssätt.
Här är ett exempel som underklassar från django.test.TestCase, som är en underklass av unittest.TestCase som kör varje test inuti en transaktion för att ge isolering:
from django.test import TestCase\nfrom myapp.models import Animal\n\n\nclass AnimalTestCase(TestCase):\n def setUp(self):\n Animal.objects.create(name="lion", sound="roar")\n Animal.objects.create(name="cat", sound="meow")\n\n def test_animals_can_speak(self):\n """Animals that can speak are correctly identified"""\n lion = Animal.objects.get(name="lion")\n cat = Animal.objects.get(name="cat")\n self.assertEqual(lion.speak(), 'The lion says "roar"')\n self.assertEqual(cat.speak(), 'The cat says "meow"')\nNär du kör dina tester, är standardbeteendet för testverktyget att hitta alla testfallsklasser (det vill säga underklasser till unittest.TestCase) i alla filer vars namn börjar med test, automatiskt bygga en testsvit av dessa testfallsklasser och köra sviten.
För mer information om unittest, se Python-dokumentationen.
När du har skrivit tester kan du köra dem med kommandot test i verktyget manage.py i ditt projekt:
$ ./manage.py test\nTestupptäckt baseras på unittest-modulens inbyggd testupptäckt. Som standard kommer detta att upptäcka tester i alla filer med namnet test*.py under den aktuella arbetskatalogen.
Du kan ange särskilda tester som ska köras genom att ange ett valfritt antal ”testetiketter” till ./manage.py test. Varje testetikett kan vara en fullständig Python-punktad sökväg till ett paket, en modul, en TestCase-underklass eller en testmetod. Till exempel:
# Run all the tests in the animals.tests module\n$ ./manage.py test animals.tests\n\n# Run all the tests found within the 'animals' package\n$ ./manage.py test animals\n\n# Run just one test case class\n$ ./manage.py test animals.tests.AnimalTestCase\n\n# Run just one test method\n$ ./manage.py test animals.tests.AnimalTestCase.test_animals_can_speak\nDu kan också ange en sökväg till en katalog för att hitta tester under den katalogen:
\n$ ./manage.py test animals/\nDu kan ange ett anpassat filnamnsmönster med hjälp av alternativet -p (eller --pattern) om dina testfiler har andra namn än test*.py:
$ ./manage.py test --pattern="tests_*.py"\nOm du trycker på Ctrl-C medan testerna körs, väntar testköraren på att det aktuella testet ska slutföras och avslutas sedan på ett elegant sätt. Under en elegant avslutning kommer testköraren att ge ut information om eventuella testfel, rapportera hur många tester som kördes och hur många fel och misslyckanden som uppstod, samt förstöra alla testdatabaser som vanligt. Att trycka på Ctrl-C kan alltså vara mycket användbart om du glömmer att ange alternativet --failfast, märker att vissa tester oväntat misslyckas och vill få information om misslyckandena utan att vänta på att hela testkörningen ska slutföras.
Om du inte vill vänta på att det aktuella testet ska avslutas kan du trycka på Ctrl-C en gång till så avbryts testkörningen omedelbart, men inte på ett elegant sätt. Inga detaljer om de tester som kördes före avbrottet kommer att rapporteras, och inga testdatabaser som skapats av körningen kommer att förstöras.
Tester som kräver en databas (dvs. modelltester) använder inte din ”riktiga” (produktions-) databas. Separata, tomma databaser skapas för testerna.
\nOavsett om testerna godkänns eller inte, förstörs testdatabaserna när alla tester har utförts.
\nDu kan förhindra att testdatabaserna förstörs genom att använda alternativet test --keepdb. Detta kommer att bevara testdatabasen mellan körningarna. Om databasen inte finns kommer den först att skapas. Eventuella migreringar kommer också att tillämpas för att hålla den uppdaterad.
Som beskrivs i föregående avsnitt får testdatabasen inte förstöras om en testkörning avbryts med våld. Vid nästa körning kommer du att få frågan om du vill återanvända eller förstöra databasen. Använd alternativet test --noinput för att undertrycka den frågan och automatiskt förstöra databasen. Detta kan vara användbart när du kör tester på en server för kontinuerlig integration där testerna kan avbrytas av en timeout, till exempel.
Standardnamnen på testdatabaserna skapas genom att lägga till test_ till värdet för varje NAME i DATABASES. När SQLite används kommer testerna att använda en databas i minnet som standard (dvs. databasen skapas i minnet och kringgår filsystemet helt!) Ordlistan TEST i DATABASER erbjuder ett antal inställningar för att konfigurera din testdatabas. Om du till exempel vill använda ett annat databasnamn anger du NAME i ordlistan TEST för en viss databas i DATABASES.
På PostgreSQL behöver USER också läsbehörighet till den inbyggda databasen postgres.
Förutom att använda en separat databas kommer testköraren att använda samma inställningar för databasen som du har i din inställningsfil: ENGINE, USER, HOST, etc. Testdatabasen skapas av den användare som anges av USER, så du måste se till att det angivna användarkontot har tillräckliga privilegier för att skapa en ny databas i systemet.
För finkornig kontroll över teckenkodningen i din testdatabas använder du alternativet CHARSET TEST. Om du använder MySQL kan du också använda alternativet COLLATION för att styra den specifika kollationering som används av testdatabasen. Se settings-dokumentationen för mer information om dessa och andra avancerade inställningar.
Om du använder en SQLite-databas i minnet med SQLite är shared cache aktiverat, så att du kan skriva tester med möjlighet att dela databasen mellan trådar.
\n\n\nFör att garantera att all TestCase-kod startar med en ren databas, ordnar Django test runner om testerna på följande sätt:
Alla TestCase underklasser körs först.
Därefter körs alla andra Django-baserade tester (testfallsklasser baserade på SimpleTestCase, inklusive TransactionTestCase) utan att någon särskild ordning garanteras eller upprätthålls mellan dem.
Sedan körs alla andra unittest.TestCase-tester (inklusive doctests) som kan ändra databasen utan att återställa den till dess ursprungliga tillstånd.
Du kan randomisera och/eller vända exekveringsordningen inom grupper med hjälp av alternativen test --shuffle och --reverse. Detta kan hjälpa till att säkerställa att dina tester är oberoende av varandra.
Alla initiala data som laddas i migreringar kommer endast att vara tillgängliga i TestCase-tester och inte i TransactionTestCase-tester, och dessutom endast på backends där transaktioner stöds (det viktigaste undantaget är MyISAM). Detta gäller även för tester som förlitar sig på TransactionTestCase som LiveServerTestCase och StaticLiveServerTestCase.
Django kan ladda om dessa data åt dig per testfall genom att ställa in alternativet serialized_rollback till True i kroppen av TestCase eller TransactionTestCase, men observera att detta kommer att sakta ner testsviten med ungefär 3x.
Tredjepartsappar eller de som utvecklas mot MyISAM måste ställa in detta; i allmänhet bör du dock utveckla dina egna projekt mot en transaktionsdatabas och använda TestCase för de flesta tester, och därmed inte behöva denna inställning.
Den första serialiseringen går vanligtvis mycket snabbt, men om du vill utesluta vissa appar från denna process (och snabba upp testkörningarna något) kan du lägga till dessa appar i TEST_NON_SERIALIZED_APPS.
För att förhindra att serialiserade data laddas två gånger, inaktiverar inställningen serialized_rollback=True post_migrate-signalen när testdatabasen rensas.
Oavsett värdet på inställningen DEBUG i din konfigurationsfil körs alla Django-tester med :setting:`DEBUG`=False. Detta är för att säkerställa att den observerade utmatningen av din kod matchar vad som kommer att ses i en produktionsinställning.
Cacher rensas inte efter varje test, och om du kör manage.py test fooapp kan data från testerna infogas i cacheminnet i ett live-system om du kör dina tester i produktion eftersom, till skillnad från databaser, en separat ”testcache” inte används. Detta beteende kan komma att ändras i framtiden.
När du kör dina tester kommer du att se ett antal meddelanden när testköraren förbereder sig. Du kan styra detaljnivån i dessa meddelanden med alternativet verbosity på kommandoraden:
Creating test database...\nCreating table myapp_animal\nCreating table myapp_mineral\nDetta visar att testköraren skapar en testdatabas, enligt beskrivningen i föregående avsnitt.
\nNär testdatabasen har skapats kommer Django att köra dina tester. Om allt går bra kommer du att se något liknande detta:
\n----------------------------------------------------------------------\nRan 22 tests in 0.221s\n\nOK\nOm testerna misslyckas kommer du dock att se fullständig information om vilka tester som misslyckades:
\n======================================================================\nFAIL: test_was_published_recently_with_future_poll (polls.tests.PollMethodTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n File "/dev/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_poll\n self.assertIs(future_poll.was_published_recently(), False)\nAssertionError: True is not False\n\n----------------------------------------------------------------------\nRan 1 test in 0.003s\n\nFAILED (failures=1)\nEn fullständig förklaring av denna felutmatning ligger utanför ramen för detta dokument, men den är ganska intuitiv. Du kan läsa dokumentationen för Pythons unittest-bibliotek för mer information.
Observera att returkoden för testrunner-skriptet är 1 för varje antal misslyckade tester (oavsett om misslyckandet orsakades av ett fel, ett misslyckat påstående eller en oväntad framgång). Om alla tester godkänns är returkoden 0. Den här funktionen är användbar om du använder testrunner-skriptet i ett shell-skript och behöver testa om det lyckas eller misslyckas på den nivån.
\nSå länge dina tester är ordentligt isolerade kan du köra dem parallellt för att få högre hastighet på flerkärnig maskinvara. Se test --parallel.
Standardalgoritmen för lösenordshashning är ganska långsam av designskäl. Om du autentiserar många användare i dina tester kanske du vill använda en anpassad inställningsfil och ställa in PASSWORD_HASHERS till en snabbare hash-algoritm:
PASSWORD_HASHERS = [\n "django.contrib.auth.hashers.MD5PasswordHasher",\n]\nGlöm inte att i PASSWORD_HASHERS även ange den hash-algoritm som används i fixturerna, om någon.
Alternativet test --keepdb bevarar testdatabasen mellan testkörningar. Det hoppar över åtgärderna för att skapa och förstöra, vilket kan minska tiden för att köra tester avsevärt.
Klassen:~django.core.files.storage.InMemoryStorage är ett bekvämt sätt att förhindra diskåtkomst för mediefiler. All data sparas i minnet och kasseras sedan efter testkörningen.
\n