# Django 6.0.7 documentation

# Avancerade testämnen

## Förfrågningsfabriken

class RequestFactory

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.

API:et för `RequestFactory` är en något begränsad delmängd av testklientens API:

- It only has access to the HTTP methods `get()`, `post()`, `put()`, `delete()`, `head()`, `options()`, 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.

### Exempel

Följande är ett enhetstest som använder request factory:

    from django.contrib.auth.models import AnonymousUser, User
    from django.test import RequestFactory, TestCase

    from .views import MyView, my_view

    class SimpleTest(TestCase):
        def setUp(self):
            # Every test needs access to the request factory.
            self.factory = RequestFactory()
            self.user = User.objects.create_user(
                username="jacob", email="jacob@…", password="top_secret"
            )

        def test_details(self):
            # Create an instance of a GET request.
            request = self.factory.get("/customer/details")

            # Recall that middleware are not supported. You can simulate a
            # logged-in user by setting request.user manually.
            request.user = self.user

            # Or you can simulate an anonymous user by setting request.user to
            # an AnonymousUser instance.
            request.user = AnonymousUser()

            # Test my_view() as if it were deployed at /customer/details
            response = my_view(request)
            # Use this syntax for class-based views.
            response = MyView.as_view()(request)
            self.assertEqual(response.status_code, 200)

### AsyncRequestFactory

class AsyncRequestFactory

`RequestFactory` 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.

## Testning av klassbaserade vyer

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:

`Vyer.py`

    from django.views.generic import TemplateView

    class HomeView(TemplateView):
        template_name = "myapp/home.html"

        def get_context_data(self, **kwargs):
            kwargs["environment"] = "Production"
            return super().get_context_data(**kwargs)

Du 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.py`

    from django.test import RequestFactory, TestCase
    from .views import HomeView

    class HomePageTest(TestCase):
        def test_environment_set_in_context(self):
            request = RequestFactory().get("/")
            view = HomeView()
            view.setup(request)

            context = view.get_context_data()
            self.assertIn("environment", context)

## Tester och flera värdnamn

Instä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:

    from django.test import TestCase

    class SearchFormTestCase(TestCase):
        def test_empty_get(self):
            response = self.client.get(
                "/en/dev/search/",
                headers={"host": "docs.djangoproject.dev:8000"},
            )
            self.assertEqual(response.status_code, 200)

och inställningsfilen innehåller en lista över de domäner som stöds av projektet:

    ALLOWED_HOSTS = ["www.djangoproject.dev", "docs.djangoproject.dev", ...]

Another option is to add the required hosts to `ALLOWED_HOSTS` using `override_settings()` or `modify_settings`. This option may be preferable in standalone apps that can’t package their own settings file or for projects where the list of domains is not static (e.g., subdomains for multitenancy). For example, you could write a test for the domain `http://otherserver/` as follows:

    from django.test import TestCase, override_settings

    class MultiDomainTestCase(TestCase):
        @override_settings(ALLOWED_HOSTS=["otherserver"])
        def test_other_domain(self):
            response = self.client.get("http://otherserver/foo/bar/")

Om 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.

## Tester och flera databaser

### Test av primär/replikakonfigurationer

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.

Fö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:

    DATABASES = {
        "default": {
            "ENGINE": "django.db.backends.mysql",
            "NAME": "myproject",
            "HOST": "dbprimary",
            # ... plus some other settings
        },
        "replica": {
            "ENGINE": "django.db.backends.mysql",
            "NAME": "myproject",
            "HOST": "dbreplica",
            "TEST": {
                "MIRROR": "default",
            },
            # ... plus some other settings
        },
    }

I 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`.

### Kontroll av skapandeordning för testdatabaser

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 = {
        "default": {
            # ... db settings
            "TEST": {
                "DEPENDENCIES": ["diamonds"],
            },
        },
        "diamonds": {
            # ... db settings
            "TEST": {
                "DEPENDENCIES": [],
            },
        },
        "clubs": {
            # ... db settings
            "TEST": {
                "DEPENDENCIES": ["diamonds"],
            },
        },
        "spades": {
            # ... db settings
            "TEST": {
                "DEPENDENCIES": ["diamonds", "hearts"],
            },
        },
        "hearts": {
            # ... db settings
            "TEST": {
                "DEPENDENCIES": ["diamonds", "clubs"],
            },
        },
    }

I 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å.

## Avancerade funktioner i `TransactionTestCase`

TransactionTestCase.available_apps

  Varning

  Detta attribut är ett privat API. Det kan komma att ändras eller tas bort i framtiden utan en avvecklingsperiod, t.ex. för att tillgodose förändringar i applikationsladdning.

  Den används för att optimera Djangos egen testsvit, som innehåller hundratals modeller men inga relationer mellan modeller i olika applikationer.

  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.

TransactionTestCase.reset_sequences

  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):
          reset_sequences = True

          def test_animal_pk(self):
              lion = Animal.objects.create(name="lion", sound="roar")
              # lion.pk is guaranteed to always be 1
              self.assertEqual(lion.pk, 1)

  Unless you are explicitly testing primary keys sequence numbers, it is recommended that you do not hardcode primary key values in tests.

  Om du använder `reset_sequences = True` kommer testet att gå långsammare, eftersom återställningen av primärnyckeln är en relativt dyr databasoperation.

## Genomför sekventiell körning av testklasser

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

    from django.test import TestCase
    from django.test.testcases import SerializeMixin

    class ImageTestCaseMixin(SerializeMixin):
        lockfile = __file__

        def setUp(self):
            self.filename = os.path.join(temp_storage_dir, "my_file.png")
            self.file = create_file(self.filename)

    class RemoveImageTests(ImageTestCaseMixin, TestCase):
        def test_remove_image(self):
            os.remove(self.filename)
            self.assertFalse(os.path.exists(self.filename))

    class ResizeImageTests(ImageTestCaseMixin, TestCase):
        def test_resize_image(self):
            resize_image(self.file, (48, 48))
            self.assertEqual(get_image_size(self.file), (48, 48))

## Använda Django Test Runner för att testa återanvändbara applikationer

Om 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.

En vanlig metod är en tests-katalog bredvid applikationskoden, med följande struktur:

    runtests.py
    polls/
        __init__.py
        models.py
        ...
    tests/
        __init__.py
        models.py
        test_settings.py
        tests.py

Låt oss ta en titt på några av dessa filer:

`runtests.py`

    #!/usr/bin/env python
    import os
    import sys

    import django
    from django.conf import settings
    from django.test.utils import get_runner

    if __name__ == "__main__":
        os.environ["DJANGO_SETTINGS_MODULE"] = "tests.test_settings"
        django.setup()
        TestRunner = get_runner(settings)
        test_runner = TestRunner()
        failures = test_runner.run_tests(["tests"])
        sys.exit(bool(failures))

Detta ä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.

Fö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.

`tester/tester_settings.py`

    SECRET_KEY = "fake-key"
    INSTALLED_APPS = [
        "tests",
    ]

Den här filen innehåller de Django-inställningar som krävs för att köra appens tester.

Även detta är ett minimalt exempel; dina tester kan kräva ytterligare inställningar för att köras.

Eftersom 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`.

## Användning av olika testramverk

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:

1. Utföra global förtestinställning.

2. Letar efter tester i alla filer under den aktuella katalogen vars namn matchar mönstret `test*.py`.

3. Skapa testdatabaserna.

4. Kör `migrate` för att installera modeller och initialdata i testdatabaserna.

5. Kör systemkontroller.

6. Kör de tester som hittades.

7. Förstöring av testdatabaserna.

8. 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.

### Definiera en testlöpare

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.

class DiscoverRunner(pattern='test*.py', top_level=None, verbosity=1, interactive=True, failfast=False, keepdb=False, reverse=False, debug_mode=False, debug_sql=False, parallel=0, tags=None, exclude_tags=None, test_name_patterns=None, pdb=False, buffer=False, enable_faulthandler=True, timing=True, shuffle=False, logger=None, durations=None, **kwargs)

  `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 than `1`, the test suite will run in `parallel` processes. If there are fewer test case classes than configured processes, Django will reduce the number of processes accordingly. Each process gets its own database. This option requires the third-party `tblib` package to display tracebacks correctly.

  `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 enabled.

  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. If provided, the logger will be used to log messages instead of printing to the console. The logger object will respect its logging level rather than the `verbosity`.

  `durations` will show a list of the N slowest test cases. Setting this option 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.

#### Attribut

DiscoverRunner.test_suite

  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.

DiscoverRunner.test_runner

  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.

DiscoverRunner.test_loader

  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.

#### Metoder

DiscoverRunner.run_tests(test_labels, **kwargs)

  Kör testsviten.

  med `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.

classmethod DiscoverRunner.add_arguments(parser)

  Override this class method to add custom arguments accepted by the `test` management command. See `argparse.ArgumentParser.add_argument()` for details about adding arguments to a parser.

DiscoverRunner.setup_test_environment(**kwargs)

  Ställer in testmiljön genom att anropa `setup_test_environment()` och ställa in `DEBUG` till `self.debug_mode` (standard är `False`).

DiscoverRunner.build_suite(test_labels=None, **kwargs)

  Konstruerar en testsvit som matchar de testetiketter som anges.

  `test_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.

DiscoverRunner.setup_databases(**kwargs)

  Skapar testdatabaserna genom att anropa `setup_databases()`.

DiscoverRunner.run_checks(databases)

  Kör systemkontroller på testets `databaser`.

DiscoverRunner.run_suite(suite, **kwargs)

  Kör testsviten.

  Returnerar resultatet av körningen av testsviten.

DiscoverRunner.get_test_runner_kwargs()

  Returnerar nyckelordsargumenten för att instansiera `DiscoverRunner.test_runner` med.

DiscoverRunner.teardown_databases(old_config, **kwargs)

  Förstör testdatabaserna och återställer villkoren före testet genom att anropa `teardown_databases()`.

DiscoverRunner.teardown_test_environment(**kwargs)

  Återställer miljön före testet.

DiscoverRunner.suite_result(suite, result, **kwargs)

  Beräknar och returnerar en returkod baserad på en testsvit och resultatet från denna testsvit.

DiscoverRunner.log(msg, level=None)

  Om 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`.

### Test av verktyg

#### `django.test.utils`

För att hjälpa till att skapa din egen testlöpare tillhandahåller Django ett antal verktygsmetoder i modulen `django.test.utils`.

setup_test_environment(debug=None)

  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.

  Om `debug` inte är `None`, uppdateras `DEBUG`-inställningen till dess värde.

teardown_test_environment()

  Utför global nedmontering efter test, t.ex. avlägsnande av instrument från mallsystemet och återställning av normala e-posttjänster.

setup_databases(verbosity, interactive, *, time_keeper=None, keepdb=False, debug_sql=False, parallel=0, aliases=None, serialized_aliases=None, **kwargs)

  Skapar testdatabaserna.

  Returnerar 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`.

teardown_databases(old_config, parallel=0, keepdb=False)

  Förstör testdatabaserna och återställer förhållandena före testet.

  `old_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.creation`

Skapandemodulen för databasens backend innehåller också några verktyg som kan vara användbara under testning.

create_test_db(verbosity=1, autoclobber=False, keepdb=False)

  Skapar 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.

  `create_test_db()` har som bieffekt att värdet för `NAME` i `DATABASES` ändras så att det motsvarar namnet på testdatabasen.

  Ersatt sedan version 6.0: The `serialize` keyword argument is deprecated. Passing `serialize=True` would automatically call `serialize_db_to_string()` but it was deprecated as it could result in queries against non-test databases during serialization.

destroy_test_db(old_database_name, verbosity=1, keepdb=False)

  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.

serialize_db_to_string()

  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.

  Denna 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.

## Integration med `coverage.py`

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.

Django 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

Detta 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:

    coverage report

Observera 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.