--- title: "Testverktyg" version: 5.2 locale: sv source: https://docs.djangoproject.com/sv/5.2/topics/testing/tools/ canonical: https://djangodocs.dev/sv/5.2/topics/testing/tools/ --- # Testverktyg Django tillhandahåller en liten uppsättning verktyg som är användbara när du skriver tester. ## Testklienten 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ågra av de saker du kan göra med testklienten är följande: - 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. - Se kedjan av omdirigeringar (om det finns några) och kontrollera webbadressen och statuskoden i varje steg. - Testa att en given begäran återges av en given Django-mall, med en mallkontext som innehåller vissa värden. Observera att testklienten inte är avsedd att ersätta [Selenium](https://www.selenium.dev/) eller andra ramverk ”i webbläsaren”. Djangos testklient har ett annat fokus. Kort och gott: - Använd Djangos testklient för att fastställa att rätt mall återges och att mallen får rätt kontextdata. - Använd [`RequestFactory`](/sv/5.2/topics/testing/advanced/#django.test.RequestFactory) för att testa vyfunktioner direkt, förbi routing- och middleware-lagren. - Använd ramverk i webbläsaren som [Selenium](https://www.selenium.dev/) 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`](#django.test.LiveServerTestCase) för mer information. En omfattande testsvit bör använda en kombination av alla dessa testtyper. ### Översikt och ett snabbt exempel För att använda testklienten, instansiera `django.test.Client` och hämta webbsidor: ```pycon >>> from django.test import Client >>> c = Client() >>> response = c.post("/login/", {"username": "john", "password": "smith"}) >>> response.status_code 200 >>> response = c.get("/customer/details/") >>> response.content b' overhead och hanterar Django-ramverket direkt. Detta hjälper till att få enhetstesterna att köras snabbt. - 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: ```pycon >>> c.get("/login/") ``` Detta är felaktigt: ```pycon >>> c.get("https://www.example.com/login/") ``` 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`](https://docs.python.org/3/library/urllib.html#module-urllib). - För att lösa URL:er använder testklienten den URLconf som pekas ut av din inställning [`ROOT_URLCONF`](/sv/5.2/ref/settings/#std-setting-ROOT_URLCONF). - Ä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*. 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. - Som standard kommer testklienten att inaktivera alla CSRF-kontroller som utförs av din webbplats. 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: ```pycon >>> from django.test import Client >>> csrf_client = Client(enforce_csrf_checks=True) ``` ### Att göra förfrågningar Använd klassen `django.test.Client` för att göra förfrågningar. #### `class Client(enforce_csrf_checks=False, raise_request_exception=True, json_encoder=DjangoJSONEncoder, * (Keyword-only parameters separator (PEP 3102)), headers=None, query_params=None, **defaults)` En testande HTTP-klient. Tar emot flera argument som kan anpassa beteendet. 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: ``` client = Client(headers={"user-agent": "curl/7.79.1"}) ``` med `query_params` kan du ange standardfrågesträngen som kommer att ställas in vid varje förfrågan. Godtyckliga nyckelordsargument i `**defaults` ställer in WSGI [**environ-variabler**](https://peps.python.org/pep-3333/#environ-variables). Till exempel, för att ställa in skriptnamnet: ``` client = Client(SCRIPT_NAME="/app/") ``` > **Note** > > Nyckelordsargument som börjar med prefixet `HTTP_` anges som rubriker, men parametern `headers` bör föredras för läsbarhetens skull. Värdena från nyckelordsargumenten `headers`, `query_params` och `extra` som skickas till [`get()`](#django.test.Client.get), [`post()`](#django.test.Client.post) etc. har företräde framför de standardvärden som skickas till klasskonstruktören. Argumentet `enforce_csrf_checks` kan användas för att testa CSRF-skydd (se ovan). 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`. Argumentet `json_encoder` gör det möjligt att ange en anpassad JSON-kodare för JSON-serialiseringen som beskrivs i [`post()`](#django.test.Client.post). > **Changed in Django 5.1** > > Argumentet `query_params` har lagts till. När du har en `Client`-instans kan du anropa någon av följande metoder: #### `get(path, data=None, follow=False, secure=False, * (Keyword-only parameters separator (PEP 3102)), headers=None, query_params=None, **extra)` Gör en GET-begäran på den angivna `path` och returnerar ett `Response`-objekt, som dokumenteras nedan. Nyckel-värdeparen i ordlistan `query_params` används för att ställa in frågesträngar. Ett exempel: ```pycon >>> c = Client() >>> c.get("/customers/details/", query_params={"name": "fred", "age": 7}) ``` …kommer att resultera i en utvärdering av en GET-begäran som motsvarar: ```text /customers/details/?name=fred&age=7 ``` Det är också möjligt att skicka dessa parametrar till parametern `data`. `query_params` är dock att föredra eftersom den fungerar för alla HTTP-metoder. Parametern `headers` kan användas för att ange vilka rubriker som ska skickas i begäran. Till exempel: ```pycon >>> c = Client() >>> c.get( ... "/customers/details/", ... query_params={"name": "fred", "age": 7}, ... headers={"accept": "application/json"}, ... ) ``` …skickar HTTP-huvudet `HTTP_ACCEPT` till detaljvyn, vilket är ett bra sätt att testa kodvägar som använder [`django.http.HttpRequest.accepts()`](/sv/5.2/ref/request-response/#django.http.HttpRequest.accepts)-metoden. Godtyckliga nyckelordsargument ställer in WSGI [**environ-variabler**](https://peps.python.org/pep-3333/#environ-variables). Till exempel headers för att ange skriptnamnet: ```pycon >>> c = Client() >>> c.get("/", SCRIPT_NAME="/app/") ``` 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: ```pycon >>> c = Client() >>> c.get("/customers/details/?name=fred&age=7") ``` 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. 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. Om du hade en URL `/redirect_me/` som omdirigerades till `/next/`, som omdirigerades till `/final/`, är det här vad du skulle se: ```pycon >>> response = c.get("/redirect_me/", follow=True) >>> response.redirect_chain [('http://testserver/next/', 302), ('http://testserver/final/', 302)] ``` Om du anger `secure` till `True` kommer klienten att emulera en HTTPS-begäran. > **Changed in Django 5.1** > > Argumentet `query_params` har lagts till. #### `post(path, data=None, content_type=MULTIPART_CONTENT, follow=False, secure=False, * (Keyword-only parameters separator (PEP 3102)), headers=None, query_params=None, **extra)` Gör en POST-begäran på den angivna `path` och returnerar ett `Response`-objekt, som dokumenteras nedan. Nyckel-värdeparen i ordlistan `data` används för att skicka POST-data. Till exempel: ```pycon >>> c = Client() >>> c.post("/login/", {"name": "fred", "passwd": "secret"}) ``` …kommer att resultera i en utvärdering av en POST-begäran till denna URL: ```text /login/ ``` …med denna POST-data: ```text name=fred&passwd=secret ``` Om du anger `content_type` som `application/json`, serialiseras `data` med [`json.dumps()`](https://docs.python.org/3/library/json.html#json.dumps) om det är en dict, lista eller tuple. Serialisering utförs med [`DjangoJSONEncoder`](/sv/5.2/topics/serialization/#django.core.serializers.json.DjangoJSONEncoder) som standard, och kan åsidosättas genom att tillhandahålla ett `json_encoder` argument till [`Client`](#django.test.Client). Denna serialisering sker också för [`put()`](#django.test.Client.put), [`patch()`](#django.test.Client.patch) och [`delete()`](#django.test.Client.delete) förfrågningar. 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`. 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. Om du vill skicka in flera värden för en viss nyckel - t.ex. för att ange urvalen för en `', '', ) ``` `html1` och `html2` måste innehålla HTML. Ett `AssertionError` kommer att uppstå om en av dem inte kan tolkas. Utdata i händelse av fel kan anpassas med argumentet `msg`. #### `SimpleTestCase.assertHTMLNotEqual(html1, html2, msg=None)` Påstår att strängarna `html1` och `html2` är *inte* lika. Jämförelsen baseras på HTML-semantik. Se [`assertHTMLEqual()`](#django.test.SimpleTestCase.assertHTMLEqual) för detaljer. `html1` och `html2` måste innehålla HTML. Ett `AssertionError` kommer att uppstå om en av dem inte kan tolkas. Utdata i händelse av fel kan anpassas med argumentet `msg`. #### `SimpleTestCase.assertXMLEqual(xml1, xml2, msg=None)` Påstår att strängarna `xml1` och `xml2` är lika. Jämförelsen baseras på XML-semantik. På samma sätt som [`assertHTMLEqual()`](#django.test.SimpleTestCase.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. XML-deklaration, dokumenttyp, bearbetningsinstruktioner och kommentarer ignoreras. Endast rotelementet och dess underordnade element jämförs. Utdata i händelse av fel kan anpassas med argumentet `msg`. #### `SimpleTestCase.assertXMLNotEqual(xml1, xml2, msg=None)` Påstår att strängarna `xml1` och `xml2` är *inte* lika. Jämförelsen är baserad på XML-semantik. Se [`assertXMLEqual()`](#django.test.SimpleTestCase.assertXMLEqual) för detaljer. Utdata i händelse av fel kan anpassas med argumentet `msg`. #### `SimpleTestCase.assertInHTML(needle, haystack, count=None, msg_prefix='')` Påstår att HTML-fragmentet `needle` ingår i `haystack` en gång. Om heltalsargumentet `count` anges, kommer dessutom antalet förekomster av `nålar` att kontrolleras noggrant. I de flesta fall ignoreras blanksteg och attributordningen är inte signifikant. Se [`assertHTMLEqual()`](#django.test.SimpleTestCase.assertHTMLEqual) för mer information. > **Changed in Django 5.1** > > I äldre versioner innehöll felmeddelanden inte `haystack`. #### `SimpleTestCase.assertNotInHTML(needle, haystack, msg_prefix='')` > **New in Django 5.1** Påstår att HTML-fragmentet `needle` *inte* ingår i `haystack`. I de flesta fall ignoreras blanksteg och attributordningen är inte signifikant. Se [`assertHTMLEqual()`](#django.test.SimpleTestCase.assertHTMLEqual) för mer information. #### `SimpleTestCase.assertJSONEqual(raw, expected_data, msg=None)` 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`](https://docs.python.org/3/library/json.html#module-json)-biblioteket. Utdata i händelse av fel kan anpassas med argumentet `msg`. #### `SimpleTestCase.assertJSONNotEqual(raw, expected_data, msg=None)` Säger att JSON-fragmenten `raw` och `expected_data` *inte* är lika. Se [`assertJSONEqual()`](#django.test.SimpleTestCase.assertJSONEqual) för ytterligare detaljer. Utdata i händelse av fel kan anpassas med argumentet `msg`. #### `TransactionTestCase.assertQuerySetEqual(qs, values, transform=None, ordered=True, msg=None)` Säger att en frågeuppsättning `qs` matchar en viss iterabel av värden `values`. Om `transform` anges, jämförs `values` med en lista som framställs genom att `transform` tillämpas på varje medlem i `qs`. 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å. Utdata i händelse av fel kan anpassas med argumentet `msg`. #### `TransactionTestCase.assertNumQueries(num, func, *args, **kwargs)` Säger att när `func` anropas med `*args` och `**kwargs` så körs `num` databasfrågor. Om en `"using"`-nyckel finns i `kwargs` används den som databasalias för att kontrollera antalet frågor: ``` self.assertNumQueries(7, my_function, using="non_default_db") ``` Om du vill anropa en funktion med en `using` parameter kan du göra det genom att omsluta anropet med en `lambda` för att lägga till en extra parameter: ``` self.assertNumQueries(7, lambda: my_function(using=7)) ``` Du kan också använda detta som en kontexthanterare: ``` with self.assertNumQueries(2): Person.objects.create(name="Aaron") Person.objects.create(name="Daniel") ``` ### Taggning av tester Du kan märka dina tester så att du enkelt kan köra en viss delmängd. Du kan till exempel märka snabba eller långsamma tester: ``` from django.test import tag class SampleTestCase(TestCase): @tag("fast") def test_fast(self): ... @tag("slow") def test_slow(self): ... @tag("slow", "core") def test_slow_but_core(self): ... ``` Du kan också tagga en testfallsklass: ``` @tag("slow", "core") class SampleTestCase(TestCase): ... ``` Underklasser ärver taggar från överklasser och metoder ärver taggar från sin klass. Givet: ``` @tag("foo") class SampleTestCaseChild(SampleTestCase): @tag("bar") def test(self): ... ``` `SampleTestCaseChild.test` kommer att märkas med `'slow'`, `'core'`, `'bar'` och `'foo'`. Sedan kan du välja vilka tester som ska köras. Till exempel om du bara vill köra snabba tester: ```console $ ./manage.py test --tag=fast ``` *Windows* ```doscon ...\> manage.py test --tag=fast ``` Eller för att köra snabba tester och kärntesten (även om den är långsam): ```console $ ./manage.py test --tag=fast --tag=core ``` *Windows* ```doscon ...\> manage.py test --tag=fast --tag=core ``` Du kan också utesluta tester med hjälp av taggar. För att köra kärntester om de inte är långsamma: ```console $ ./manage.py test --tag=core --exclude-tag=slow ``` *Windows* ```doscon ...\> manage.py test --tag=core --exclude-tag=slow ``` [`test --exclude-tag`](/sv/5.2/ref/django-admin/#cmdoption-test-exclude-tag) har företräde framför [`test --tag`](/sv/5.2/ref/django-admin/#cmdoption-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. ## Testning av asynkron kod 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. Men om du vill skriva helt asynkrona tester för ett Django-projekt måste du ta hänsyn till flera saker. För det första måste dina tester vara `async def`-metoder på testklassen (för att ge dem ett asynkront sammanhang). Django kommer automatiskt att upptäcka alla `async def`-tester och linda in dem så att de körs i sin egen händelseslinga. 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. #### `class AsyncClient(enforce_csrf_checks=False, raise_request_exception=True, * (Keyword-only parameters separator (PEP 3102)), headers=None, query_params=None, **defaults)` `AsyncClient` har samma metoder och signaturer som den synkrona (normala) testklienten, med följande undantag: - Vid initialiseringen läggs godtyckliga nyckelordsargument i `defaults` till direkt i ASGI-scopet. - Headers som skickas som `extra` nyckelordsargument bör inte ha prefixet `HTTP_` som krävs av den synkrona klienten (se [`Client.get()`](#django.test.Client.get)). Till exempel, så här ställer du in en HTTP `Accept` header: ```pycon >>> c = AsyncClient() >>> c.get("/customers/details/", {"name": "fred", "age": 7}, ACCEPT="application/json") ``` > **Changed in Django 5.1** > > Argumentet `query_params` har lagts till. Med hjälp av `AsyncClient` måste alla metoder som gör en begäran väntas: ``` async def test_my_thing(self): response = await self.async_client.get("/some-url/") self.assertEqual(response.status_code, 200) ``` Den asynkrona klienten kan också anropa synkrona vyer; den körs genom Djangos [asynkrona sökväg](/sv/5.2/topics/async/), 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. > **Warning** > > Om du använder testdekoratorer måste de vara async-kompatibla för att säkerställa att de fungerar korrekt. Djangos inbyggda dekoratorer kommer att bete sig korrekt, men dekoratorer från tredje part kan verka som om de inte exekveras (de kommer att ”linda in” fel del av exekveringsflödet och inte ditt test). > > Om du behöver använda dessa dekoratorer, bör du dekorera dina testmetoder med [`async_to_sync()`](/sv/5.2/topics/async/#asgiref.sync.async_to_sync) *inom* dem istället: > > ``` > from asgiref.sync import async_to_sync > from django.test import TestCase > > > class MyTests(TestCase): > @mock.patch(...) > @async_to_sync > async def test_my_thing(self): ... > ``` ## E-posttjänster Om någon av dina Django-vyer skickar e-post med hjälp av [Djangos e-postfunktionalitet](/sv/5.2/topics/email/), vill du förmodligen inte skicka e-post varje gång du kör ett test med den vyn. Av denna anledning omdirigerar Djangos testlöpare automatiskt all Django-skickad e-post till en dummy-utkorg. Detta gör att du kan testa alla aspekter av att skicka e-post - från antalet meddelanden som skickas till innehållet i varje meddelande - utan att faktiskt skicka meddelandena. Testlöparen åstadkommer detta genom att transparent ersätta den normala e-postbackend med en testbackend. (Oroa dig inte - detta har ingen effekt på andra e-postavsändare utanför Django, till exempel din maskins e-postserver, om du kör en sådan) #### `django.core.mail.outbox` Under testkörning sparas varje utgående e-postmeddelande i `django.core.mail.outbox`. Detta är en lista över alla [`EmailMessage`](/sv/5.2/topics/email/#django.core.mail.EmailMessage)-instanser som har skickats. Attributet `outbox` är ett specialattribut som skapas *endast* när e-postbackend `locmem` används. Det existerar normalt inte som en del av modulen [`django.core.mail`](/sv/5.2/topics/email/#module-django.core.mail) och du kan inte importera det direkt. Koden nedan visar hur man kommer åt detta attribut på rätt sätt. Här är ett exempel på ett test som undersöker `django.core.mail.outbox` för längd och innehåll: ``` from django.core import mail from django.test import TestCase class EmailTest(TestCase): def test_send_email(self): # Send message. mail.send_mail( "Subject here", "Here is the message.", "from@example.com", ["to@example.com"], fail_silently=False, ) # Test that one message has been sent. self.assertEqual(len(mail.outbox), 1) # Verify that the subject of the first message is correct. self.assertEqual(mail.outbox[0].subject, "Subject here") ``` Som nämnts [tidigare](#emptying-test-outbox), 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`: ``` from django.core import mail # Empty the test outbox mail.outbox = [] ``` ## Kommandon för hantering Hanteringskommandon kan testas med funktionen [`call_command()`](/sv/5.2/ref/django-admin/#django.core.management.call_command). Utdata kan omdirigeras till en `StringIO`-instans: ``` from io import StringIO from django.core.management import call_command from django.test import TestCase class ClosepollTest(TestCase): def test_command_output(self): out = StringIO() call_command("closepoll", poll_ids=[1], stdout=out) self.assertIn('Successfully closed poll "1"', out.getvalue()) ``` ## Skippa prov Biblioteket unittest tillhandahåller dekoratorerna [`@skipIf`](https://docs.python.org/3/library/unittest.html#unittest.skipIf) och [`@skipUnless`](https://docs.python.org/3/library/unittest.html#unittest.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. Om ditt test till exempel kräver ett visst valfritt bibliotek för att lyckas, kan du dekorera testfallet med [`@skipIf`](https://docs.python.org/3/library/unittest.html#unittest.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. 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. 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](https://github.com/django/django/blob/stable/5.2.x/django/db/backends/base/features.py) för en fullständig lista över databasfunktioner som kan användas som grund för att hoppa över tester. #### `skipIfDBFeature(*feature_name_strings)` Hoppa över det dekorerade testet eller `TestCase` om alla de namngivna databasfunktionerna stöds. 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): ``` class MyTests(TestCase): @skipIfDBFeature("supports_transactions") def test_transaction_behavior(self): # ... conditional test code pass ``` #### `skipUnlessDBFeature(*feature_name_strings)` Hoppa över det dekorerade testet eller `TestCase` om någon av de namngivna databasfunktionerna *inte* stöds. 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): ``` class MyTests(TestCase): @skipUnlessDBFeature("supports_transactions") def test_transaction_behavior(self): # ... conditional test code pass ```