{"title":"Testverktyg","version":"6.1","locale":"sv","docname":"topics/testing/tools","url":"/sv/6.1/topics/testing/tools/","canonical":"https://djangodocs.dev/sv/6.1/topics/testing/tools/","summary":"Django tillhandahåller en liten uppsättning verktyg som är användbara när du skriver tester. Testklienten Link to this heading # Testklienten är en Python-klass som…","html":"
Testklienten är en Python-klass som fungerar som en dummy-webbläsare, så att du kan testa dina vyer och interagera med din Django-drivna applikation programmatiskt.
\n
Några av de saker du kan göra med testklienten är följande:
\n
\n
Simulera GET- och POST-begäranden på en URL och observera svaret - allt från HTTP på låg nivå (resultathuvuden och statuskoder) till sidinnehåll.
\n
Se kedjan av omdirigeringar (om det finns några) och kontrollera webbadressen och statuskoden i varje steg.
\n
Testa att en given begäran återges av en given Django-mall, med en mallkontext som innehåller vissa värden.
\n
\n
Observera att testklienten inte är avsedd att ersätta Selenium eller andra ramverk ”i webbläsaren”. Djangos testklient har ett annat fokus. Kort och gott:
\n
\n
Använd Djangos testklient för att fastställa att rätt mall återges och att mallen får rätt kontextdata.
\n
Använd RequestFactory för att testa vyfunktioner direkt, förbi routing- och middleware-lagren.
\n
Använd ramverk i webbläsaren som Selenium för att testa renderad HTML och beteendet på webbsidor, nämligen JavaScript-funktionalitet. Django ger också särskilt stöd för dessa ramverk; se avsnittet om LiveServerTestCase för mer information.
\n
\n
En omfattande testsvit bör använda en kombination av alla dessa testtyper.
Som exemplet visar kan du instansiera Client från en session i den interaktiva Python-tolken.
\n
Notera några viktiga saker om hur testklienten fungerar:
\n
\n
Testklienten kräver inte att webbservern är igång. Faktum är att det går alldeles utmärkt utan att någon webbserver körs alls! Det beror på att den undviker HTTP:s overhead och hanterar Django-ramverket direkt. Detta hjälper till att få enhetstesterna att köras snabbt.
\n
När du hämtar sidor ska du komma ihåg att ange sökvägen i URL:en, inte hela domänen. Detta är till exempel korrekt:
\n
Python console
>>> c.get("/login/")\n
\n
Detta är felaktigt:
\n
Python console
>>> c.get("https://www.example.com/login/")\n
\n
Testklienten kan inte hämta webbsidor som inte drivs av ditt Django-projekt. Om du behöver hämta andra webbsidor kan du använda en modul från Pythons standardbibliotek, t.ex. urllib.
\n
\n
För att lösa URL:er använder testklienten den URLconf som pekas ut av din inställning ROOT_URLCONF.
\n
Även om ovanstående exempel skulle fungera i Pythons interaktiva tolk, är en del av testklientens funktionalitet, särskilt den mallrelaterade funktionaliteten, endast tillgänglig när tester körs.
\n
Anledningen till detta är att Djangos testlöpare utför lite svart magi för att avgöra vilken mall som laddades av en viss vy. Denna svarta magi (i huvudsak en patchning av Djangos mallsystem i minnet) sker endast under testkörning.
\n
\n
Som standard kommer testklienten att inaktivera alla CSRF-kontroller som utförs av din webbplats.
\n
Om du av någon anledning vill att testklienten ska utföra CSRF-kontroller kan du skapa en instans av testklienten som tvingar fram CSRF-kontroller. För att göra detta, skicka in argumentet enforce_csrf_checks när du konstruerar din klient:
Använd klassen django.test.Client för att göra förfrågningar.
\n
\n
\nclassClient(enforce_csrf_checks=False, raise_request_exception=True, json_encoder=DjangoJSONEncoder, *, headers=None, query_params=None, **defaults)Link to this definition#
\n
En testande HTTP-klient. Tar emot flera argument som kan anpassa beteendet.
\n
med headers kan du ange standardrubriker som ska skickas med varje begäran. Till exempel, för att ställa in en User-Agent header:
med query_params kan du ange standardfrågesträngen som kommer att ställas in vid varje förfrågan.
\n
Godtyckliga nyckelordsargument i **defaults ställer in WSGI environ-variabler. Till exempel, för att ställa in skriptnamnet:
\n
Code
client=Client(SCRIPT_NAME="/app/")\n
\n\n
The values from the headers, query_params, and extra keyword\narguments passed to get(),\npost(), etc. have precedence over\nthe defaults passed to the class constructor.
\n
Argumentet enforce_csrf_checks kan användas för att testa CSRF-skydd (se ovan).
\n
Argumentet raise_request_exception gör det möjligt att kontrollera om undantag som uppstår under begäran också ska uppstå i testet. Standardvärdet är True.
\n
Argumentet json_encoder gör det möjligt att ange en anpassad JSON-kodare för JSON-serialiseringen som beskrivs i post().
\n
När du har en Client-instans kan du anropa någon av följande metoder:
\n
\n
\nget(path, data=None, follow=False, secure=False, *, headers=None, query_params=None, **extra)Link to this definition#
\n
Gör en GET-begäran på den angivna path och returnerar ett Response-objekt, som dokumenteras nedan.
\n
Nyckel-värdeparen i ordlistan query_params används för att ställa in frågesträngar. Ett exempel:
…will send the HTTP header HTTP_ACCEPT to the details view, which\nis a good way to test code paths that use the\ndjango.http.HttpRequest.accepts() method.
\n
Godtyckliga nyckelordsargument ställer in WSGI environ-variabler. Till exempel headers för att ange skriptnamnet:
Om du redan har GET-argumenten i URL-kodad form kan du använda den kodningen i stället för att använda data-argumentet. Till exempel kan den föregående GET-begäran också ställas som:
Om du anger en URL med både kodade GET-data och antingen ett query_params- eller data-argument kommer dessa argument att ha företräde.
\n
Om du anger follow till True kommer klienten att följa alla omdirigeringar och ett redirect_chain-attribut kommer att anges i svarsobjektet som innehåller tuples av de mellanliggande webbadresserna och statuskoderna.
\n
Om du hade en URL /redirect_me/ som omdirigerades till /next/, som omdirigerades till /final/, är det här vad du skulle se:
…kommer att resultera i en utvärdering av en POST-begäran till denna URL:
\n
Text
/login/\n
\n
…med denna POST-data:
\n
Text
name=fred&passwd=secret\n
\n
Om du anger content_type som application/json, serialiseras data med json.dumps() om det är en dict, lista eller tuple. Serialisering utförs med DjangoJSONEncoder som standard, och kan åsidosättas genom att tillhandahålla ett json_encoder argument till Client. Denna serialisering sker också för put(), patch() och delete() förfrågningar.
\n
Om du anger någon annan content_type (t.ex. text/xml för en XML-nyttolast) skickas innehållet i data som det är i POST-begäran, med content_type i HTTP-rubriken Content-Type.
\n
Om du inte anger något värde för content_type kommer värdena i data att överföras med en innehållstyp av multipart/form-data. I det här fallet kommer nyckel-värdeparen i data att kodas som ett multipartmeddelande och användas för att skapa POST-datanyttolasten.
\n
Om du vill skicka in flera värden för en viss nyckel - t.ex. för att ange urvalen för en <selectmultiple> - ska du ange värdena som en lista eller tupel för den nyckel som krävs. Till exempel skulle detta värde av data skicka tre valda värden för fältet med namnet choices:
\n
Code
{"choices":["a","b","d"]}\n
\n
Att skicka filer är ett specialfall. För att POSTa en fil behöver du bara ange filfältets namn som en nyckel och ett filhandtag till filen du vill ladda upp som ett värde. Om ditt formulär till exempel har fälten name och attachment, är det senare en FileField:
Du kan också tillhandahålla vilket filliknande objekt som helst (t.ex. StringIO eller BytesIO) som ett filhandtag. Om du laddar upp till en ImageField behöver objektet ett name-attribut som skickar validate_image_file_extension-validatorn. Till exempel:
Observera att om du vill använda samma filhandtag för flera post()-anrop måste du manuellt återställa filpekaren mellan inläggen. Det enklaste sättet att göra detta är att manuellt stänga filen efter att den har levererats till post(), som demonstreras ovan.
\n
Du bör också se till att filen öppnas på ett sätt som gör det möjligt att läsa data. Om filen innehåller binära data, t.ex. en bild, innebär det att du måste öppna filen i läget rb (read binary).
\n
Parametrarna headers, query_params och extra fungerar på samma sätt som för Client.get().
\n
Om URL:en som du begär med en POST innehåller kodade parametrar, kommer dessa parametrar att göras tillgängliga i request.GET-data. Om du t.ex. skulle göra begäran:
… kan vyn som hanterar denna begäran fråga request.POST för att hämta användarnamn och lösenord, och kan fråga request.GET för att avgöra om användaren var en besökare.
\n
Om du anger follow till True kommer klienten att följa alla omdirigeringar och ett redirect_chain-attribut kommer att anges i svarsobjektet som innehåller tuples av de mellanliggande webbadresserna och statuskoderna.
\n
Om du anger secure till True kommer klienten att emulera en HTTPS-begäran.
\n
\n\n
\n
\nhead(path, data=None, follow=False, secure=False, *, headers=None, query_params=None, **extra)Link to this definition#
\n
Gör en HEAD-förfrågan på den angivna path och returnerar ett Response-objekt. Denna metod fungerar precis som Client.get(), inklusive parametrarna follow, secure, headers, query_params och extra, förutom att den inte returnerar en meddelandekropp.
\n
\n\n
\n
\noptions(path, data='', content_type='application/octet-stream', follow=False, secure=False, *, headers=None, query_params=None, **extra)Link to this definition#
\n
Gör en OPTIONS-begäran på den angivna vägen och returnerar ett svar-objekt. Användbart för att testa RESTful-gränssnitt.
\n
När data tillhandahålls används det som förfrågningsunderlag och ett Content-Type-huvud sätts till content_type.
\n
Parametrarna follow, secure, headers, query_params och extra fungerar på samma sätt som för Client.get().
\n
\n\n
\n
\nput(path, data='', content_type='application/octet-stream', follow=False, secure=False, *, headers=None, query_params=None, **extra)Link to this definition#
\n
Gör en PUT-förfrågan på den angivna path och returnerar ett Response-objekt. Användbart för att testa RESTful-gränssnitt.
\n
När data tillhandahålls används det som förfrågningsunderlag och ett Content-Type-huvud sätts till content_type.
\n
Parametrarna follow, secure, headers, query_params och extra fungerar på samma sätt som för Client.get().
\n
\n\n
\n
\npatch(path, data='', content_type='application/octet-stream', follow=False, secure=False, *, headers=None, query_params=None, **extra)Link to this definition#
\n
Gör en PATCH-förfrågan på den angivna banan och returnerar ett svar-objekt. Användbart för att testa RESTful-gränssnitt.
\n
Parametrarna follow, secure, headers, query_params och extra fungerar på samma sätt som för Client.get().
\n
\n\n
\n
\ndelete(path, data='', content_type='application/octet-stream', follow=False, secure=False, *, headers=None, query_params=None, **extra)Link to this definition#
\n
Gör en DELETE-begäran på den angivna vägen och returnerar ett svar-objekt. Användbart för att testa RESTful-gränssnitt.
\n
När data tillhandahålls används det som förfrågningsunderlag och ett Content-Type-huvud sätts till content_type.
\n
Parametrarna follow, secure, headers, query_params och extra fungerar på samma sätt som för Client.get().
\n
\n\n
\n
\ntrace(path, follow=False, secure=False, *, headers=None, query_params=None, **extra)Link to this definition#
\n
Gör en TRACE-begäran på den angivna vägen och returnerar ett svar-objekt. Användbar för att simulera diagnostiska prober.
\n
Till skillnad från de andra förfrågningsmetoderna tillhandahålls inte data som en nyckelordsparameter för att följa RFC 9110 Section 9.3.8, som föreskriver att TRACE-förfrågningar inte får ha en kropp.
\n
Parametrarna follow, secure, headers, query_params och extra fungerar på samma sätt som för Client.get().
Om din webbplats använder Djangos authentication system och du hanterar inloggning av användare, kan du använda testklientens login()-metod för att simulera effekten av att en användare loggar in på webbplatsen.
\n
När du anropar den här metoden kommer testklienten att ha alla cookies och sessionsdata som krävs för att klara inloggningsbaserade tester som kan ingå i en vy.
\n
Formatet på argumentet credentials beror på vilken authentication backend <authentication-backends>` du använder (som konfigureras av din AUTHENTICATION_BACKENDS-inställning). Om du använder standardautentiseringsbackend som tillhandahålls av Django (ModelBackend), bör credentials vara användarens användarnamn och lösenord, som tillhandahålls som nyckelordsargument:
\n
Python console
>>> c=Client()\n>>> c.login(username="fred",password="secret")\n\n# Now you can access a view that's only available to logged-in users.\n
\n
Om du använder en annan autentiseringsbackend kan den här metoden kräva andra referenser. Den kräver de autentiseringsuppgifter som krävs av din backends authenticate() metod.
\n
login() returns True if the credentials were accepted and\nlogin was successful.
\n
Finally, you’ll need to remember to create user accounts before you can\nuse this method. As we explained above, the test runner is executed\nusing a test database, which contains no users by default. As a result,\nuser accounts that are valid on your production site will not work\nunder test conditions. You’ll need to create users as part of the test\nsuite – either manually (using the Django model API) or with a test\nfixture. Remember that if you want your test user to have a password,\nyou can’t set the user’s password by setting the password attribute\ndirectly – you must use the\nset_password() function to\nstore a correctly hashed password. Alternatively, you can use the\ncreate_user() helper\nmethod to create a new user with a correctly hashed password.
Om din webbplats använder Djangos authentication system kan du använda metoden force_login() för att simulera effekten av att en användare loggar in på webbplatsen. Använd den här metoden istället för login() när ett test kräver att en användare är inloggad och detaljerna om hur en användare loggar in inte är viktiga.
\n
Till skillnad från login() hoppar den här metoden över autentiserings- och verifieringsstegen: inaktiva användare (is_active=False) tillåts logga in och användarens autentiseringsuppgifter behöver inte anges.
\n
Användaren kommer att ha sitt backend-attribut inställt till värdet av backend-argumentet (som bör vara en prickad Python-sökvägssträng), eller till settings.AUTHENTICATION_BACKENDS[0] om ett värde inte tillhandahålls. Funktionen authenticate() som anropas av login() annoterar normalt användaren så här.
\n
Den här metoden är snabbare än login() eftersom de dyra hashingalgoritmerna för lösenord kringgås. Du kan också snabba upp login() genom att använda en svagare hasher när du testar.
Om din webbplats använder Djangos autentiseringssystem, kan metoden logout() användas för att simulera effekten av att en användare loggar ut från din webbplats.
\n
När du har anropat den här metoden kommer testklienten att ha alla cookies och sessionsdata rensade till standardvärden. Efterföljande förfrågningar kommer att se ut att komma från en AnonymousUser.
Metoderna get() och post() returnerar båda ett Response-objekt. Detta Response-objekt är inte samma som HttpResponse-objektet som returneras av Django-vyer; testsvarsobjektet har några ytterligare data som är användbara för testkod för att verifiera.
\n
Specifikt har ett Response-objekt följande attribut:
Mallen Context-instans som användes för att rendera den mall som producerade svarsinnehållet.
\n
Om den renderade sidan använde flera mallar kommer context att vara en lista med Context-objekt, i den ordning de renderades.
\n
Oavsett hur många mallar som används vid rendering kan du hämta kontextvärden med operatorn []. Exempelvis kan kontextvariabeln name hämtas med hjälp av:
En lista över Template-instanser som används för att rendera det slutliga innehållet, i den ordning de renderades. För varje mall i listan, använd template.name för att få mallens filnamn, om mallen laddades från en fil. (Namnet är en sträng som till exempel 'admin/index.html'.)
En instans av ResolverMatch för svaret. Du kan till exempel använda attributet func för att verifiera den vy som serverade svaret:
\n
Code
# my_view here is a function based view.\nself.assertEqual(response.resolver_match.func,my_view)\n\n# Class-based views need to compare the view_class, as the\n# functions generated by as_view() won't be equal.\nself.assertIs(response.resolver_match.func.view_class,MyView)\n
\n
Om den angivna URL:en inte hittas kommer åtkomst till detta attribut att ge upphov till ett Resolver404 undantag.
\n
\n\n
\n\n
Precis som med ett vanligt svar kan du också komma åt rubrikerna via HttpResponse.headers. Du kan till exempel bestämma innehållstypen i ett svar med hjälp av response.headers['Content-Type'].
Om du riktar testklienten mot en vy som ger upphov till ett undantag och Client.raise_request_exception är True, kommer undantaget att vara synligt i testfallet. Du kan sedan använda ett standardblock try...except eller assertRaises() för att testa för undantag.
\n
De enda undantagen som inte är synliga för testklienten är Http404, PermissionDenied, SystemExit, och SuspiciousOperation. Django fångar dessa undantag internt och omvandlar dem till lämpliga HTTP-svarskoder. I dessa fall kan du kontrollera response.status_code i ditt test.
\n
Om Client.raise_request_exception är False kommer testklienten att returnera ett 500-svar som skulle returneras till en webbläsare. Svaret har attributet exc_info för att ge information om det ohanterade undantaget.
Testklienten är tillståndsbaserad. Om ett svar returnerar en cookie, kommer denna cookie att lagras i testklienten och skickas med alla efterföljande get()- och post()-förfrågningar.
\n
Utgångspolicyerna för dessa cookies följs inte. Om du vill att en cookie ska upphöra att gälla måste du antingen ta bort den manuellt eller skapa en ny instans av Client (vilket i praktiken innebär att alla cookies tas bort).
\n
En testklient har attribut som lagrar information om beständigt tillstånd. Du kan komma åt dessa egenskaper som en del av ett testvillkor.
Ett Python SimpleCookie-objekt som innehåller de aktuella värdena för alla klientcookies. Se dokumentationen för modulen http.cookies för mer information.
Ett ordboksliknande objekt som innehåller sessionsinformation. Se session documentation för fullständig information.
\n
För att ändra sessionen och sedan spara den måste den först lagras i en variabel (eftersom en ny SessionStore skapas varje gång denna egenskap används):
När du testar applikationer som stöder internationalisering och lokalisering kanske du vill ställa in språket för en testklientbegäran. Metoden för att göra detta beror på om LocaleMiddleware är aktiverad eller inte.
\n
Om middleware är aktiverat kan språket ställas in genom att skapa en cookie med namnet LANGUAGE_COOKIE_NAME och ett värde som motsvarar språkkoden:
\n
Code
fromdjango.confimportsettings\n\n\ndeftest_language_using_cookie(self):\n self.client.cookies.load({settings.LANGUAGE_COOKIE_NAME:"fr"})\n response=self.client.get("/")\n self.assertEqual(response.content,b"Bienvenue sur mon site.")\n
\n
eller genom att inkludera HTTP-huvudet Accept-Language i begäran:
\n
Code
deftest_language_using_header(self):\n response=self.client.get("/",headers={"accept-language":"fr"})\n self.assertEqual(response.content,b"Bienvenue sur mon site.")\n
Följande är ett enhetstest med hjälp av testklienten:
\n
Code
importunittest\nfromdjango.testimportClient\n\n\nclassSimpleTest(unittest.TestCase):\n defsetUp(self):\n # Every test needs a client.\n self.client=Client()\n\n deftest_details(self):\n # Issue a GET request.\n response=self.client.get("/customer/details/")\n\n # Check that the response is 200 OK.\n self.assertEqual(response.status_code,200)\n\n # Check that the rendered context contains 5 customers.\n self.assertEqual(len(response.context["customers"]),5)\n
Du kan konvertera en normal unittest.TestCase till någon av underklasserna: ändra basklassen för ditt test från unittest.TestCase till underklassen. Alla Pythons standardfunktioner för enhetstester kommer att finnas tillgängliga, och de kommer att kompletteras med några användbara tillägg som beskrivs i varje avsnitt nedan.
SimpleTestCase tillåter inte databasfrågor som standard. Detta hjälper till att undvika att skriva frågor som påverkar andra tester eftersom varje SimpleTestCase-test inte körs i en transaktion. Om du inte är orolig för det här problemet kan du inaktivera det här beteendet genom att ställa in klassattributet databases till '__all__' på din testklass.
Django’s TestCase class is a more commonly used subclass of\nTransactionTestCase that makes use of database transaction facilities\nto speed up the process of resetting the database to a known state at the\nend of each test. A consequence of this, however, is that some database\nbehaviors cannot be tested within a Django TestCase class. For instance,\nyou cannot test that a block of code is executing within a transaction, as is\nrequired when using\nselect_for_update(). In those cases,\nyou should use TransactionTestCase.
\n
TransactionTestCase och TestCase är identiska med undantag för det sätt på vilket databasen återställs till ett känt tillstånd och möjligheten för testkoden att testa effekterna av commit och rollback:
\n
\n
Ett TransactionTestCase återställer databasen efter testkörningen genom att trunkera alla tabeller. Ett TransactionTestCase kan anropa commit och rollback och observera effekterna av dessa anrop på databasen.
\n
Ett TestCase trunkerar däremot inte tabeller efter ett test. Istället innesluts testkoden i en databastransaktion som rullas tillbaka i slutet av testet. Detta garanterar att rollback i slutet av testet återställer databasen till dess ursprungliga tillstånd.
Detta är den vanligaste klassen att använda för att skriva tester i Django. Den ärver från TransactionTestCase (och i förlängningen SimpleTestCase). Om din Django-applikation inte använder en databas, använd SimpleTestCase.
\n
Klassen:
\n
\n
Omsluter testerna i två nästlade atomic()-block: ett för hela klassen och ett för varje test. Därför, om du vill testa något specifikt databas transaktionsbeteende, använd TransactionTestCase.
\n
Kontrollerar uppskjutbara databasbegränsningar i slutet av varje test.
Det atomiska block på klassnivå som beskrivs ovan gör det möjligt att skapa initialdata på klassnivå, en gång för hela TestCase. Denna teknik möjliggör snabbare tester jämfört med att använda setUp().
\n
Till exempel:
\n
Code
fromdjango.testimportTestCase\n\n\nclassMyTests(TestCase):\n @classmethod\n defsetUpTestData(cls):\n # Set up data for the whole TestCase\n cls.foo=Foo.objects.create(bar="Test")\n ...\n\n deftest1(self):\n # Some test using self.foo\n ...\n\n deftest2(self):\n # Some other test using self.foo\n ...\n
\n
Observera att om testerna körs på en databas utan transaktionsstöd (t.ex. MySQL med MyISAM-motorn) kommer setUpTestData() att anropas före varje test, vilket upphäver hastighetsfördelarna.
\n
Objects assigned to class attributes in setUpTestData() must support\ncreating deep copies with copy.deepcopy() in order to isolate them\nfrom alterations performed by each test methods.
\n
\n\n
\n
\nclassmethodTestCase.captureOnCommitCallbacks(using=DEFAULT_DB_ALIAS, execute=False)Link to this definition#
\n
Returnerar en kontexthanterare som fångar upp transaction.on_commit() callbacks för den angivna databasanslutningen. Den returnerar en lista som innehåller, vid avslutning av kontexten, de fångade återuppringningsfunktionerna. Från den här listan kan du göra påståenden om återuppringningarna eller anropa dem för att åberopa deras sidoeffekter, vilket emulerar en commit.
\n
using är aliaset för den databasanslutning för vilken återuppringningar ska registreras.
\n
Om execute är True kommer alla callbacks att anropas när kontexthanteraren avslutas, om inget undantag inträffade. Detta emulerar en commit efter det omslutna kodblocket.
\n
Till exempel:
\n
Code
fromdjango.coreimportmail\nfromdjango.testimportTestCase\n\n\nclassContactTests(TestCase):\n deftest_post(self):\n withself.captureOnCommitCallbacks(execute=True)ascallbacks:\n response=self.client.post(\n "/contact/",\n {"message":"I like your site"},\n )\n\n self.assertEqual(response.status_code,200)\n self.assertEqual(len(callbacks),1)\n self.assertEqual(len(mail.outbox),1)\n self.assertEqual(mail.outbox[0].subject,"Contact Form")\n self.assertEqual(mail.outbox[0].body,"I like your site")\n
LiveServerTestCase gör i princip samma sak som TransactionTestCase med en extra funktion: den startar en live Django-server i bakgrunden vid installationen och stänger av den vid nedmonteringen. Detta gör det möjligt att använda andra automatiserade testklienter än Django dummy client som till exempel Selenium-klienten, för att utföra en serie funktionella tester i en webbläsare och simulera en riktig användares handlingar.
\n
Live-servern lyssnar på localhost och binder till port 0 som använder en fri port som tilldelas av operativsystemet. Serverns URL kan nås med self.live_server_url under testerna.
\n
För att visa hur man använder LiveServerTestCase, låt oss skriva ett Selenium-test. Först och främst måste du installera paketet selenium:
\n
Linux / macOS
Shell
$ python-mpipinstall"selenium >= 4.23.0"\n
\n
Windows
Windows
...\\> py -m pip install "selenium >= 4.23.0"\n
\n
Lägg sedan till ett LiveServerTestCase-baserat test i din apps testmodul (till exempel: myapp/tests.py). I det här exemplet antar vi att du använder staticfiles-appen och vill ha statiska filer serverade under körningen av dina tester liknande det vi får vid utvecklingstid med DEBUG=True, dvs. utan att behöva samla in dem med collectstatic. Vi kommer att använda StaticLiveServerTestCase subklassen som tillhandahåller den funktionaliteten. Ersätt den med django.test.LiveServerTestCase om du inte behöver det.
...\\> manage.py test myapp.tests.MySeleniumTests.test_login\n
\n
Detta exempel kommer automatiskt att öppna Firefox och sedan gå till inloggningssidan, ange inloggningsuppgifterna och trycka på knappen ”Logga in”. Selenium erbjuder andra drivrutiner om du inte har Firefox installerat eller vill använda en annan webbläsare. Exemplet ovan är bara en liten bråkdel av vad Selenium-klienten kan göra; kolla in full reference för mer information.
Every django.test.*TestCase instance has access to Django’s synchronous\nand asynchronous test clients as self.client and self.async_client,\nrespectively. Both clients are recreated for each test, so you don’t have to\nworry about state (such as cookies) carrying over from one test to another.
\n
For example, rather than instantiating a Client in each test:
For example, to customize the synchronous test client:
\n
Code
fromdjango.testimportClient,TestCase\n\n\nclassMyTestClient(Client):\n # Specialized methods for your environment\n ...\n\n\nclassMyTest(TestCase):\n client_class=MyTestClient\n\n deftest_my_stuff(self):\n # Here self.client is an instance of MyTestClient...\n call_some_test_code()\n
\n
The same pattern applies to the asynchronous test client by subclassing\nAsyncClient and setting async_client_class.
En testfallsklass för en databasbaserad webbplats är inte till någon större nytta om det inte finns några data i databasen. Tester är mer läsbara och det är mer underhållbart att skapa objekt med hjälp av ORM, till exempel i TestCase.setUpTestData(), men du kan också använda fixtures.
\n
En fixtur är en samling data som Django vet hur man importerar till en databas. Om din webbplats till exempel har användarkonton kan du skapa en fixtur med falska användarkonton för att fylla på din databas under tester.
\n
Det enklaste sättet att skapa en fixtur är att använda kommandot manage.pydumpdata. Detta förutsätter att du redan har en del data i din databas. Se dumpdatadocumentation för mer information.
\n
När du har skapat en fixtur och placerat den i en fixtures katalog i en av dina INSTALLED_APPS, kan du använda den i dina enhetstester genom att ange ett fixtures klassattribut på din django.test.TestCase subclass:
\n
Code
fromdjango.testimportTestCase\nfrommyapp.modelsimportAnimal\n\n\nclassAnimalTestCase(TestCase):\n fixtures=["mammals.json","birds"]\n\n defsetUp(self):\n # Test definitions as before.\n call_setup_methods()\n\n deftest_fluffy_animals(self):\n # A test that uses the fixtures.\n call_some_test_code()\n
\n
Det här är vad som kommer att hända i detalj:
\n
\n
Under setUpClass() installeras alla namngivna fixturer. I det här exemplet kommer Django att installera alla JSON-fixturer med namnet mammals, följt av alla fixturer med namnet birds. Se ämnet Fixturer för mer information om hur man definierar och installerar fixturer.
\n
\n
För de flesta enhetstester som använder TestCase behöver Django inte göra något annat, eftersom transaktioner används för att rensa databasen efter varje test av prestandaskäl. Men för TransactionTestCase kommer följande åtgärder att äga rum:
\n
\n
I slutet av varje test kommer Django att spola databasen, vilket återställer databasen till det tillstånd den befann sig i direkt efter att migrate anropades.
\n
För varje efterföljande test kommer fixturerna att laddas om innan setUp() körs.
\n
\n
I vilket fall som helst kan du vara säker på att resultatet av ett test inte kommer att påverkas av ett annat test eller av ordningen på testgenomförandet.
\n
Som standard laddas fixturer endast in i databasen default. Om du använder flera databaser och anger TransactionTestCase.databases kommer fixturer att laddas i alla angivna databaser.
Om din applikation innehåller vyer kanske du vill inkludera tester som använder testklienten för att aktivera dessa vyer. Det står dock en slutanvändare fritt att distribuera vyerna i din applikation till vilken URL som helst. Detta innebär att dina tester inte kan förlita sig på att dina vyer kommer att finnas tillgängliga på en viss URL. Dekorera din testklass eller testmetod med @override_settings(ROOT_URLCONF=...) för URLconf-konfiguration.
Django skapar en testdatabas som motsvarar varje databas som definieras i DATABASER-definitionen i dina inställningar och som minst ett test hänvisar till via databaser.
\n
En stor del av den tid det tar att köra ett Django TestCase förbrukas dock av anropet till flush som säkerställer att du har en ren databas i slutet av varje testkörning. Om du har flera databaser krävs flera spolningar (en för varje databas), vilket kan vara en tidskrävande aktivitet - särskilt om dina tester inte behöver testa aktivitet i flera databaser.
\n
Som en optimering spolar Django bara databasen default i slutet av varje testkörning. Om din installation innehåller flera databaser och du har ett test som kräver att alla databaser är rena, kan du använda attributet databaser på testsviten för att begära att extra databaser spolas.
Denna testfallsklass kommer att rensa testdatabaserna default och other efter att ha kört test_index_page_view. Du kan också använda '__all__' för att ange att alla testdatabaser måste rensas.
\n
Flaggan databases styr också vilka databaser som TransactionTestCase.fixtures laddas in i. Som standard laddas fixturerna endast in i databasen default.
\n
Frågor mot databaser som inte finns i databaser kommer att ge assertionfel för att förhindra att tillstånd läcker mellan tester.
Som standard kommer endast standard-databasen att omslutas av en transaktion under exekveringen av ett TestCase och försök att fråga andra databaser kommer att resultera i assertionfel för att förhindra att tillstånd läcker mellan tester.
\n
Använd klassattributet databases på testklassen för att begära transaktionsomslag mot databaser som inte är standard.
Detta test tillåter endast frågor mot databasen other. Precis som för SimpleTestCase.databases och TransactionTestCase.databases kan konstanten '__all__' användas för att ange att testet ska tillåta frågor till alla databaser.
For testing purposes it’s often useful to change a setting temporarily and\nrevert to the original value after running the testing code. For this use case\nDjango provides a standard context manager called\nsettings(), which can be used like this:
\n
Code
fromdjango.testimportTestCase\n\n\nclassLoginTestCase(TestCase):\n deftest_login(self):\n # First check for the default behavior\n response=self.client.get("/sekrit/")\n self.assertRedirects(response,"/accounts/login/?next=/sekrit/")\n\n # Then override the LOGIN_URL setting\n withself.settings(LOGIN_URL="/other/login/"):\n response=self.client.get("/sekrit/")\n self.assertRedirects(response,"/other/login/?next=/sekrit/")\n
\n
Detta exempel åsidosätter inställningen LOGIN_URL för koden i with-blocket och återställer dess värde till det tidigare tillståndet efteråt.
Det kan vara krångligt att omdefiniera inställningar som innehåller en lista med värden. I praktiken är det ofta tillräckligt att lägga till eller ta bort värden. Django tillhandahåller kontexthanteraren modify_settings() för enklare ändringar av inställningar:
För varje åtgärd kan du ange antingen en lista med värden eller en sträng. När värdet redan finns i listan har append och prepend ingen effekt; det har inte heller remove när värdet inte finns.
När du åsidosätter inställningar måste du se till att hantera de fall där din appkod använder en cache eller liknande funktion som behåller tillståndet även om inställningen ändras. Django tillhandahåller django.test.signals.setting_changed-signalen som låter dig registrera återuppringningar för att städa upp och på annat sätt återställa tillståndet när inställningarna ändras.
\n
Django själv använder denna signal för att återställa olika data:
Registrerar de modeller som definieras i en omsluten kontext i sitt eget isolerade apps-register. Denna funktion är användbar när du skapar modellklasser för tester, eftersom klasserna kommer att raderas rent efteråt och det inte finns någon risk för namnkollisioner.
\n
De appetiketter som det isolerade registret ska innehålla måste skickas som enskilda argument. Du kan använda isolate_apps() som en dekorator eller en kontexthanterare. Till exempel:
attr_name: attribut som tilldelas det isolerade registret om det används som en klassdekorator.
\n
kwarg_name: nyckelordsargument som skickar det isolerade registret om det används som en funktionsdekorator.
\n
\n
Den tillfälliga instansen Apps som används för att isolera modellregistreringen kan hämtas som ett attribut när den används som en klassdekorator genom att använda parametern attr_name:
Precis som Pythons normala klass unittest.TestCase implementerar assertion-metoder som assertTrue() och assertEqual(), tillhandahåller Djangos anpassade klass TestCase ett antal anpassade assertion-metoder som är användbara för att testa webbapplikationer:
\n
De felmeddelanden som ges av de flesta av dessa assertion-metoder kan anpassas med argumentet msg_prefix. Denna sträng kommer att prefixeras till alla felmeddelanden som genereras av påståendet. Detta gör att du kan ge ytterligare information som kan hjälpa dig att identifiera platsen för och orsaken till ett fel i din testsvit.
\n
\n
\nSimpleTestCase.assertRaisesMessage(expected_exception, expected_message, callable, *args, **kwargs)Link to this definition#
Säger att exekvering av callable ger upphov till expected_exception och att expected_message finns i undantagets meddelande. Alla andra resultat rapporteras som ett misslyckande. Det är en enklare version av unittest.TestCase.assertRaisesRegex() med skillnaden att expected_message inte behandlas som ett reguljärt uttryck.
\n
Om endast parametrarna expected_exception och expected_message anges, returneras en kontexthanterare så att den kod som testas kan skrivas inline i stället för som en funktion:
\n
Code
withself.assertRaisesMessage(ValueError,"invalid literal for int()"):\n int("a")\n
\n
\n\n
\n
\nSimpleTestCase.assertWarnsMessage(expected_warning, expected_message, callable, *args, **kwargs)Link to this definition#
Säger att ett fält i ett formulär ger upphov till den angivna listan med fel.
\n
form är en Form instans. Formuläret måste vara bundet men inte nödvändigtvis validerat (assertFormError() kommer automatiskt att anropa full_clean() på formuläret).
\n
field är namnet på det fält i formuläret som ska kontrolleras. För att kontrollera formulärets icke-fältfel, använd field=None.
\n
errors är en lista med alla felsträngar som fältet förväntas ha. Du kan också skicka en enda felsträng om du bara förväntar dig ett fel, vilket innebär att errors='errormessage' är detsamma som errors=['errormessage'].
\n
\n\n
\n
\nSimpleTestCase.assertFormSetError(formset, form_index, field, errors, msg_prefix='')Link to this definition#
\n
Säger att formset ger upphov till den angivna listan med fel när det renderas.
\n
formset är en instans av FormSet. Formsetet måste vara bundet men inte nödvändigtvis validerat (assertFormSetError() anropar automatiskt full_clean() på formsetet).
\n
form_index är numret på formuläret i FormSet (med början från 0). Använd form_index=None för att kontrollera formuläruppsättningens icke-formulärfel, dvs. de fel som du får när du anropar formset.non_form_errors(). I så fall måste du också använda field=None.
\n
field och errors har samma betydelse som parametrarna till assertFormError().
\n
\n\n
\n
\nSimpleTestCase.assertContains(response, text, count=None, status_code=200, msg_prefix='', html=False)Link to this definition#
\n
Asserts that an HttpResponse produced the\ngiven status_code and that text\nappears in its content. If count\nis provided, text must occur exactly count times in the response.
\n
Sätt html till True för att hantera text som HTML. Jämförelsen med svarsinnehållet kommer att baseras på HTML-semantik i stället för likhet tecken för tecken. Whitespace ignoreras i de flesta fall, attributordning är inte signifikant. Se assertHTMLEqual() för mer information.
\n
\n\n
\n
\nSimpleTestCase.assertNotContains(response, text, status_code=200, msg_prefix='', html=False)Link to this definition#
Sätt html till True för att hantera text som HTML. Jämförelsen med svarsinnehållet kommer att baseras på HTML-semantik i stället för likhet tecken för tecken. Whitespace ignoreras i de flesta fall, attributordning är inte signifikant. Se assertHTMLEqual() för mer information.
\n
\n\n
\n
\nSimpleTestCase.assertTemplateUsed(response, template_name, msg_prefix='', count=None)Link to this definition#
\n
Bekräftar att mallen med det angivna namnet användes vid rendering av svaret.
\n
response must be a Response instance returned by\nthe test client.
\n
template_name bör vara en sträng som till exempel 'admin/index.html'.
\n
Argumentet count är ett heltal som anger hur många gånger mallen ska återges. Standard är None, vilket innebär att mallen ska återges en eller flera gånger.
\n
Du kan använda detta som en kontexthanterare, så här:
Påstår att två webbadresser är desamma och ignorerar ordningen på parametrarna i frågesträngen, utom för parametrar med samma namn. Till exempel är /path/?x=1&y=2 lika med /path/?y=2&x=1, men /path/?a=1&a=2 är inte lika med /path/?a=2&a=1.
\n
\n\n
\n
\nSimpleTestCase.assertRedirects(response, expected_url, status_code=302, target_status_code=200, msg_prefix='', fetch_redirect_response=True)Link to this definition#
\n
Asserts that the HttpResponse returned a response\nwith a redirect status (based on its\nstatus_code), redirected to\nexpected_url (including any GET data), and that the final response\nwas received with target_status_code.
\n
Om din begäran använde argumentet follow kommer expected_url och target_status_code att vara webbadressen och statuskoden för den sista punkten i omdirigeringskedjan.
\n
Om fetch_redirect_response är False kommer den slutliga sidan inte att laddas. Eftersom testklienten inte kan hämta externa webbadresser är detta särskilt användbart om expected_url inte är en del av din Django-app.
\n
Schema hanteras korrekt när jämförelser görs mellan två webbadresser. Om det inte finns något schema angivet på den plats dit vi omdirigeras används den ursprungliga begärans schema. Om det finns, är det schemat i expected_url som används för att göra jämförelser.
Påstår att strängarna xml1 och xml2 är lika. Jämförelsen baseras på XML-semantik. På samma sätt som assertHTMLEqual(), görs jämförelsen på parsat innehåll, vilket innebär att endast semantiska skillnader beaktas, inte syntaxskillnader. När ogiltig XML skickas i någon parameter, uppstår alltid ett AssertionError, även om båda strängarna är identiska.
\n
XML-deklaration, dokumenttyp, bearbetningsinstruktioner och kommentarer ignoreras. Endast rotelementet och dess underordnade element jämförs.
\n
Utdata i händelse av fel kan anpassas med argumentet msg.
Påstår att JSON-fragmenten raw och expected_data är lika. Vanliga JSON-regler för icke-signifikanta blanksteg gäller eftersom tungvikten är delegerad till json-biblioteket.
\n
Utdata i händelse av fel kan anpassas med argumentet msg.
Säger att JSON-fragmenten raw och expected_datainte är lika. Se assertJSONEqual() för ytterligare detaljer.
\n
Utdata i händelse av fel kan anpassas med argumentet msg.
\n
\n\n
\n
\nTransactionTestCase.assertQuerySetEqual(qs, values, transform=None, ordered=True, msg=None)Link to this definition#
\n
Säger att en frågeuppsättning qs matchar en viss iterabel av värden values.
\n
Om transform anges, jämförs values med en lista som framställs genom att transform tillämpas på varje medlem i qs.
\n
Som standard är jämförelsen också beroende av ordning. Om qs inte tillhandahåller en implicit ordning kan du ställa in parametern ordered till False, vilket gör jämförelsen till en collections.Counter jämförelse. Om ordningen är odefinierad (om den givna qs inte är ordnad och jämförelsen är mot mer än ett ordnat värde), kommer ett ValueError att uppstå.
\n
Utdata i händelse av fel kan anpassas med argumentet msg.
SampleTestCaseChild.test kommer att märkas med 'slow', 'core', 'bar' och 'foo'.
\n
Sedan kan du välja vilka tester som ska köras. Till exempel om du bara vill köra snabba tester:
\n
Linux / macOS
Shell
$ ./manage.pytest--tag=fast\n
\n
Windows
Windows
...\\> manage.py test --tag=fast\n
\n
Eller för att köra snabba tester och kärntesten (även om den är långsam):
\n
Linux / macOS
Shell
$ ./manage.pytest--tag=fast--tag=core\n
\n
Windows
Windows
...\\> manage.py test --tag=fast --tag=core\n
\n
Du kan också utesluta tester med hjälp av taggar. För att köra kärntester om de inte är långsamma:
\n
Linux / macOS
Shell
$ ./manage.pytest--tag=core--exclude-tag=slow\n
\n
Windows
Windows
...\\> manage.py test --tag=core --exclude-tag=slow\n
\n
test--exclude-tag har företräde framför test--tag, så om ett test har två taggar och du väljer en av dem och utesluter den andra, kommer testet inte att köras.
Om du bara vill testa utdata från dina asynkrona vyer kommer standardtestklienten att köra dem i sin egen asynkrona loop utan något extra arbete från din sida.
\n
Men om du vill skriva helt asynkrona tester för ett Django-projekt måste du ta hänsyn till flera saker.
\n
För det första måste dina tester vara asyncdef-metoder på testklassen (för att ge dem ett asynkront sammanhang). Django kommer automatiskt att upptäcka alla asyncdef-tester och linda in dem så att de körs i sin egen händelseslinga.
\n
Om du testar från en asynkron funktion måste du också använda den asynkrona testklienten. Detta är tillgängligt som django.test.AsyncClient, eller som self.async_client på alla tester.
\n
\n
\nclassAsyncClient(enforce_csrf_checks=False, raise_request_exception=True, *, headers=None, query_params=None, **defaults)Link to this definition#
\n
\n\n
AsyncClient har samma metoder och signaturer som den synkrona (normala) testklienten, med följande undantag:
\n
\n
Vid initialiseringen läggs godtyckliga nyckelordsargument i defaults till direkt i ASGI-scopet.
\n
Headers som skickas som extra nyckelordsargument bör inte ha prefixet HTTP_ som krävs av den synkrona klienten (se Client.get()). Till exempel, så här ställer du in en HTTP Accept header:
Den asynkrona klienten kan också anropa synkrona vyer; den körs genom Djangos asynkrona sökväg, som stöder båda. Varje vy som anropas via AsyncClient kommer att få ett ASGIRequest-objekt för sin request snarare än WSGIRequest som den normala klienten skapar.
If any of your code sends email using Django’s email functionality, you probably don’t want to send email each time you run a\ntest that exercises that code. For this reason, Django’s test runner\nautomatically redirects all Django-sent email to an in-memory outbox. This lets\nyou test every aspect of sending email – from the number of messages sent to\nthe contents of each message – without actually sending the messages.
\n
The test runner accomplishes this by transparently replacing the\nBACKEND for each configured MAILERS\nalias with the 'locmem'memory email backend. (Don’t worry – this has no effect on any other\nemail senders outside of Django, such as your machine’s mail server, if you’re\nrunning one.)
During test running, each outgoing email is saved in\ndjango.core.mail.outbox. This is a list of all\nEmailMessage instances that have been sent. The\noutbox attribute is a special attribute that is created only when the\nlocmem email backend is used. It doesn’t normally exist as part of the\ndjango.core.mail module and you can’t import it directly. The code below\nshows how to access this attribute correctly.
\n
Här är ett exempel på ett test som undersöker django.core.mail.outbox för längd och innehåll:
\n
Code
fromdjango.coreimportmail\nfromdjango.testimportTestCase\n\n\nclassEmailTest(TestCase):\n deftest_send_email(self):\n # Send message.\n mail.send_mail(\n "Subject here",\n "Here is the message.",\n "from@example.com",\n ["to@example.com"],\n )\n\n # Test that one message has been sent.\n self.assertEqual(len(mail.outbox),1)\n\n # Verify that the subject of the first message is correct.\n self.assertEqual(mail.outbox[0].subject,"Subject here")\n\n # Verify the message was sent with the "default" mailer.\n self.assertEqual(mail.outbox[0].sent_using,"default")\n
\n\n
Som nämnts tidigare, töms testutkorgen i början av varje test i ett Django *TestCase. För att tömma utkorgen manuellt, tilldela den tomma listan till mail.outbox:
\n
Code
fromdjango.coreimportmail\n\n# Empty the test outbox\nmail.outbox=[]\n
Biblioteket unittest tillhandahåller dekoratorerna @skipIf och @skipUnless så att du kan hoppa över tester om du i förväg vet att dessa tester kommer att misslyckas under vissa förutsättningar.
\n
Om ditt test till exempel kräver ett visst valfritt bibliotek för att lyckas, kan du dekorera testfallet med @skipIf. Då kommer testköraren att rapportera att testet inte kördes och varför, istället för att misslyckas med testet eller utelämna testet helt och hållet.
\n
För att komplettera dessa testöverhoppningsbeteenden tillhandahåller Django ytterligare två skip-dekoratorer. Istället för att testa en generisk boolean, kontrollerar dessa dekoratorer databasens kapacitet och hoppar över testet om databasen inte stöder en specifik namngiven funktion.
\n
Dekoratörerna använder en strängidentifierare för att beskriva databasfunktioner. Denna sträng motsvarar attribut i klassen för databasanslutningsfunktioner. Se django.db.backends.base.features.BaseDatabaseFeatures class för en fullständig lista över databasfunktioner som kan användas som grund för att hoppa över tester.
Hoppa över det dekorerade testet eller TestCase om alla de namngivna databasfunktionerna stöds.
\n
Till exempel kommer följande test inte att utföras om databasen stöder transaktioner (t.ex. skulle det * inte * köras under PostgreSQL, men det skulle under MySQL med MyISAM-tabeller):
\n
Code
classMyTests(TestCase):\n @skipIfDBFeature("supports_transactions")\n deftest_transaction_behavior(self):\n # ... conditional test code\n pass\n
Hoppa över det dekorerade testet eller TestCase om någon av de namngivna databasfunktionerna inte stöds.
\n
Till exempel kommer följande test endast att utföras om databasen stöder transaktioner (t.ex. skulle det köras under PostgreSQL, men * inte * under MySQL med MyISAM-tabeller):
\n
Code
classMyTests(TestCase):\n @skipUnlessDBFeature("supports_transactions")\n deftest_transaction_behavior(self):\n # ... conditional test code\n pass\n
\n","rootId":"testing-tools","toc":[{"title":"Testklienten","anchor":"the-test-client","children":[{"title":"Översikt och ett snabbt exempel","anchor":"overview-and-a-quick-example","children":[]},{"title":"Att göra förfrågningar","anchor":"making-requests","children":[]},{"title":"Testning av svar","anchor":"testing-responses","children":[]},{"title":"Undantag","anchor":"exceptions","children":[]},{"title":"Beständigt tillstånd","anchor":"persistent-state","children":[]},{"title":"Ställa in språk","anchor":"setting-the-language","children":[]},{"title":"Exempel","anchor":"example","children":[]}]},{"title":"Tillhandahållna testfallsklasser","anchor":"provided-test-case-classes","children":[{"title":"SimpleTestCase","anchor":"simpletestcase","children":[]},{"title":"TransactionTestCase","anchor":"transactiontestcase","children":[]},{"title":"TestCase","anchor":"testcase","children":[]},{"title":"LiveServerTestCase","anchor":"liveservertestcase","children":[]}]},{"title":"Testfall funktioner","anchor":"test-cases-features","children":[{"title":"Standard testklient","anchor":"default-test-client","children":[]},{"title":"Anpassning av testklienten","anchor":"customizing-the-test-client","children":[]},{"title":"Lastning av fixtur","anchor":"fixture-loading","children":[]},{"title":"URLconf-konfiguration","anchor":"urlconf-configuration","children":[]},{"title":"Stöd för flera databaser","anchor":"multi-database-support","children":[]},{"title":"Åsidosätta inställningar","anchor":"overriding-settings","children":[]},{"title":"Isolera appar","anchor":"isolating-apps","children":[]},{"title":"Tömning av testboxen","anchor":"emptying-the-test-outbox","children":[]},{"title":"Påståenden","anchor":"assertions","children":[]},{"title":"Taggning av tester","anchor":"tagging-tests","children":[]}]},{"title":"Testning av asynkron kod","anchor":"testing-asynchronous-code","children":[]},{"title":"E-posttjänster","anchor":"email-services","children":[]},{"title":"Kommandon för hantering","anchor":"management-commands","children":[]},{"title":"Skippa prov","anchor":"skipping-tests","children":[]}],"breadcrumbs":[{"docname":"topics/index","title":"Använda Django","url":"/sv/6.1/topics/"},{"docname":"topics/testing/index","title":"Testning i Django","url":"/sv/6.1/topics/testing/"}],"prev":{"docname":"topics/testing/overview","title":"Skriva och köra tester","url":"/sv/6.1/topics/testing/overview/"},"next":{"docname":"topics/testing/advanced","title":"Avancerade testämnen","url":"/sv/6.1/topics/testing/advanced/"},"formats":{"html":"/sv/6.1/topics/testing/tools/","markdown":"/sv/6.1/topics/testing/tools.md","json":"/sv/6.1/topics/testing/tools.json"},"source":"https://github.com/django/django/blob/stable/6.1.x/docs/topics/testing/tools.txt","official":"https://docs.djangoproject.com/sv/6.1/topics/testing/tools/","inVersions":["6.1","6.0","5.2"],"inLocales":["en","sv","zh-hans","ga","fr","ja","id","it","pt-br","ko","es","el","pl"]}
![\"Hierarki](\"../../../../../../_images/django_unittest_classes_hierarchy.svg\")
\n\n