`unittest` — Ramverk för enhetstestning¶

(Om du redan är bekant med de grundläggande testkoncepten kanske du vill hoppa över till listan över assert-metoder.)

Ramverket för enhetstestning unittest inspirerades ursprungligen av JUnit och har en liknande smak som de stora ramverken för enhetstestning i andra språk. Det stöder testautomatisering, delning av installations- och avstängningskod för tester, aggregering av tester i samlingar och oberoende av testerna från rapporteringsramverket.

För att uppnå detta stöder unittest några viktiga koncept på ett objektorienterat sätt:

test fixture: En test fixture representerar de förberedelser som krävs för att utföra ett eller flera tester, och alla tillhörande rensningsåtgärder. Det kan t.ex. handla om att skapa tillfälliga databaser eller proxydatabaser, kataloger eller att starta en serverprocess.
test case: Ett testfall är en individuell enhet för testning. Det kontrollerar ett specifikt svar på en viss uppsättning indata. unittest tillhandahåller en basklass, TestCase, som kan användas för att skapa nya testfall.
test suite: En testsvit är en samling av testfall, testsviter eller båda. Den används för att samla ihop tester som ska utföras tillsammans.
test runner: En test runner är en komponent som orkestrerar utförandet av tester och ger resultatet till användaren. Runnern kan använda ett grafiskt gränssnitt, ett textgränssnitt eller returnera ett speciellt värde för att ange resultatet av testkörningen.

Se även

Modul doctest: En annan teststödsmodul med en helt annan smak.
Enkel testning av Smalltalk: Med mönster: Kent Becks originalartikel om testning av ramverk med hjälp av det mönster som delas av unittest.
pytest: Tredjeparts unittest-ramverk med en lättare syntax för att skriva tester. Till exempel, assert func(10) == 42.
Taxonomin för testverktyg för Python: En omfattande lista över testverktyg för Python, inklusive ramverk för funktionstestning och bibliotek med låtsasobjekt.
Sändlista för testning i Python: En specialintressegrupp för diskussion om testning och testverktyg i Python.

Skriptet Tools/unittestgui/unittestgui.py i Python-källdistributionen är ett GUI-verktyg för att upptäcka och utföra tester. Detta är främst avsett för att underlätta användningen för dem som är nya inom enhetstestning. För produktionsmiljöer rekommenderas att tester drivs av ett kontinuerligt integrationssystem som Buildbot, Jenkins, GitHub Actions eller AppVeyor.

Grundläggande exempel¶

Modulen unittest innehåller en stor uppsättning verktyg för att konstruera och köra tester. Detta avsnitt visar att en liten delmängd av verktygen räcker för att uppfylla de flesta användares behov.

Här är ett kort skript för att testa tre strängmetoder:

import unittest

class TestStringMethods(unittest.TestCase):

    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)

if __name__ == '__main__':
    unittest.main()

Ett testfall skapas genom subklassning av unittest.TestCase. De tre enskilda testerna definieras med metoder vars namn börjar med bokstäverna test. Denna namngivningskonvention informerar testlöparen om vilka metoder som representerar tester.

Kärnan i varje test är ett anrop till assertEqual() för att kontrollera ett förväntat resultat; assertTrue() eller assertFalse() för att verifiera ett villkor; eller assertRaises() för att verifiera att ett specifikt undantag tas upp. Dessa metoder används istället för assert-satsen så att testlöparen kan samla alla testresultat och producera en rapport.

Med metoderna setUp() och tearDown() kan du definiera instruktioner som ska utföras före och efter varje testmetod. De beskrivs mer i detalj i avsnittet Organisering av testkod.

Det sista blocket visar ett enkelt sätt att köra testerna. unittest.main() ger ett kommandoradsgränssnitt till testskriptet. När ovanstående skript körs från kommandoraden ger det en utdata som ser ut så här:

...
----------------------------------------------------------------------
Ran 3 tests in 0.000s

OK

Om du anger alternativet -v i ditt testskript kommer unittest.main() att aktivera en högre nivå av ordrikedom och producera följande utdata:

test_isupper (__main__.TestStringMethods.test_isupper) ... ok
test_split (__main__.TestStringMethods.test_split) ... ok
test_upper (__main__.TestStringMethods.test_upper) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.001s

OK

Exemplen ovan visar de vanligaste unittest-funktionerna som är tillräckliga för att uppfylla många vardagliga testbehov. I resten av dokumentationen utforskas hela funktionsuppsättningen från första början.

Ändrad i version 3.11: Beteendet att returnera ett värde från en testmetod (annat än standardvärdet None) är nu föråldrat.

Kommandoradsgränssnitt¶

Modulen unittest kan användas från kommandoraden för att köra tester från moduler, klasser eller till och med enskilda testmetoder:

python -m unittest test_modul1 test_modul2
python -m unittest test_modul.TestClass
python -m unittest test_modul.TestClass.test_method

Du kan skicka in en lista med valfri kombination av modulnamn och fullständigt kvalificerade klass- eller metodnamn.

Testmoduler kan också anges med filväg:

python -m unittest tester/test_något.py

Detta gör att du kan använda skalets filnamnskomplettering för att ange testmodulen. Den angivna filen måste fortfarande vara importerbar som en modul. Sökvägen konverteras till ett modulnamn genom att ”.py” tas bort och sökvägsavgränsare konverteras till ”.”. Om du vill köra en testfil som inte kan importeras som en modul bör du istället köra filen direkt.

Du kan köra tester med fler detaljer (högre verbosity) genom att skicka in flaggan -v:

python -m unittest -v test_modul

När den körs utan argument startas Testupptäckt:

python -m unittest

För en lista över alla kommandoradsalternativ:

python -m unittest -h

Ändrad i version 3.2: I tidigare versioner var det bara möjligt att köra enskilda testmetoder och inte moduler eller klasser.

Tillagd i version 3.14: Utdata är färgade som standard och kan kontrolleras med hjälp av miljövariabler.

Alternativ för kommandoraden¶

unittest stöder dessa kommandoradsalternativ:

-b, --buffer¶: Standardutdata- och standardfelströmmarna buffras under testkörningen. Utdata under ett godkänt test kasseras. Utdata ekas normalt vid misslyckat eller felaktigt test och läggs till i felmeddelandena.

-c, --catch¶

Control-C under testkörningen väntar på att det aktuella testet skall avslutas och rapporterar sedan alla resultat så här långt. En andra Control-C ger upphov till det normala KeyboardInterrupt undantaget.

Se Signalhantering för de funktioner som tillhandahåller denna funktionalitet.

-f, --failfast¶: Avbryt testkörningen vid första felet eller misslyckandet.

-k¶

Kör endast testmetoder och klasser som matchar mönstret eller delsträngen. Det här alternativet kan användas flera gånger, och då inkluderas alla testfall som matchar något av de angivna mönstren.

Mönster som innehåller ett jokertecken (*) matchas mot testnamnet med hjälp av fnmatch.fnmatchcase(); annars används enkel skiftlägeskänslig delsträngsmatchning.

Mönster matchas mot det fullständigt kvalificerade testmetodnamnet som importeras av testladdaren.

Till exempel matchar -k foo foo_tests.SomeTest.test_something, bar_tests.SomeTest.test_foo, men inte bar_tests.FooTest.test_something.

--locals¶: Visa lokala variabler i spårningar.

--durations N¶: Visa de N långsammaste testfallen (N=0 för alla).

Tillagd i version 3.2: Kommandoradsalternativen -b, -c och -f har lagts till.

Tillagd i version 3.5: Kommandoradsalternativet --locals.

Tillagd i version 3.7: Kommandoradsalternativet -k.

Tillagd i version 3.12: Kommandoradsalternativet --durations.

Kommandoraden kan också användas för att upptäcka tester, för att köra alla tester i ett projekt eller bara en delmängd.

Testupptäckt¶

Tillagd i version 3.2.

Unittest stöder enkel testupptäckt. För att vara kompatibla med testupptäckt måste alla testfiler vara modules eller packages som kan importeras från projektets toppkatalog (detta innebär att deras filnamn måste vara giltiga identifiers).

Testupptäckt implementeras i TestLoader.discover(), men kan också användas från kommandoraden. Den grundläggande kommandoradsanvändningen är:

cd projekt_katalog
python -m unittest discover

Anteckning

Som en genväg är python -m unittest ekvivalent med python -m unittest discover. Om du vill skicka argument till testdiscovery måste underkommandot discover användas explicit.

Underkommandot discover har följande alternativ:

-v, --verbose¶: Utförlig utdata

-s, --start-directory directory¶: Katalog för att starta upptäckten (. standard)

-p, --pattern pattern¶: Mönster för att matcha testfiler (test*.py standard)

-t, --top-level-directory directory¶: Projektets katalog på högsta nivån (standard är startkatalogen)

Alternativen -s, -p och -t kan anges som positionella argument i den ordningen. Följande två kommandorader är likvärdiga:

python -m unittest discover -s project_directory -p "*_test.py"
python -m unittest discover project_directory "*_test.py"

Förutom att ange en sökväg är det möjligt att ange ett paketnamn, t.ex. myproject.subpackage.test, som startkatalog. Det paketnamn som du anger importeras då och dess plats i filsystemet används som startkatalog.

Försiktighet

Test discovery laddar tester genom att importera dem. När testdiscovery har hittat alla testfiler från den startkatalog du anger omvandlar den sökvägarna till paketnamn som ska importeras. Till exempel foo/bar/baz.py importeras som foo.bar.baz.

Om du har ett paket installerat globalt och försöker utföra testdiscovery på en annan kopia av paketet, kan importen ske från fel ställe. Om detta händer kommer test discovery att varna dig och avsluta.

Om du anger startkatalogen som ett paketnamn i stället för en sökväg till en katalog antar discover att den plats som den importerar från är den plats som du avsåg, så att du inte får varningen.

Testmoduler och testpaket kan anpassa laddning och upptäckt av tester genom protokollet load_tests.

Ändrad i version 3.4: Test discovery stöder namespace packages.

Ändrad i version 3.11: Test discovery släppte namespace packages-stödet. Det har varit trasigt sedan Python 3.7. Startkatalog och dess underkataloger som innehåller tester måste vara vanliga paket som har filen __init__.py.

Om startkatalogen är paketets prickade namn kan förfäderspaketen vara namnrymdspaket.

Ändrad i version 3.14: Testupptäckt stöder namespace package som startkatalog igen. För att undvika att skanna kataloger som inte är relaterade till Python, söks inte tester i underkataloger som inte innehåller __init__.py.

Organisering av testkod¶

De grundläggande byggstenarna i enhetstestning är testfall — enskilda scenarier som måste ställas upp och kontrolleras för korrekthet. I unittest representeras testfall av unittest.TestCase-instanser. För att skapa egna testfall måste du skriva subklasser av TestCase eller använda FunctionTestCase.

Testkoden för en TestCase-instans bör vara helt fristående, så att den kan köras antingen isolerat eller i godtycklig kombination med valfritt antal andra testfall.

Den enklaste TestCase-underklassen kommer helt enkelt att implementera en testmetod (dvs. en metod vars namn börjar med test) för att utföra specifik testkod:

import unittest

class DefaultWidgetSizeTestCase(unittest.TestCase):
    def test_default_widget_size(self):
        widget = Widget('The widget')
        self.assertEqual(widget.size(), (50, 50))

Observera att för att testa något använder vi en av metoderna assert* som tillhandahålls av basklassen TestCase. Om testet misslyckas kommer ett undantag att uppstå med ett förklarande meddelande, och unittest kommer att identifiera testfallet som ett failure. Alla andra undantag kommer att behandlas som errors.

Testerna kan vara många och deras uppbyggnad kan vara repetitiv. Lyckligtvis kan vi eliminera uppstartskoden genom att implementera en metod som heter setUp(), som testramverket automatiskt anropar för varje enskilt test vi kör:

import unittest

class WidgetTestCase(unittest.TestCase):
    def setUp(self):
        self.widget = Widget('The widget')

    def test_default_widget_size(self):
        self.assertEqual(self.widget.size(), (50,50),
                         'incorrect default size')

    def test_widget_resize(self):
        self.widget.resize(100,150)
        self.assertEqual(self.widget.size(), (100,150),
                         'wrong size after resize')

Anteckning

Den ordning i vilken de olika testerna kommer att köras bestäms genom att sortera testmetodernas namn med hänsyn till den inbyggda ordningen för strängar.

Om metoden setUp() ger upphov till ett undantag medan testet körs, kommer ramverket att anse att testet har drabbats av ett fel och testmetoden kommer inte att utföras.

På samma sätt kan vi tillhandahålla en tearDown()-metod som städar upp efter att testmetoden har körts:

import unittest

class WidgetTestCase(unittest.TestCase):
    def setUp(self):
        self.widget = Widget('The widget')

    def tearDown(self):
        self.widget.dispose()

Om setUp() lyckades kommer tearDown() att köras oavsett om testmetoden lyckades eller inte.

En sådan arbetsmiljö för testkoden kallas för en testfixtur. En ny TestCase-instans skapas som en unik testfixtur som används för att utföra varje enskild testmetod. Således kommer setUp(), tearDown() och __init__() att anropas en gång per test.

Det rekommenderas att du använder TestCase-implementationer för att gruppera tester tillsammans enligt de funktioner de testar. unittest tillhandahåller en mekanism för detta: test suite, representerad av unittest:s TestSuite-klass. I de flesta fall kommer ett anrop till unittest.main() att göra det rätta och samla in alla modulens testfall åt dig och köra dem.

Men om du vill anpassa uppbyggnaden av din testsvit kan du göra det själv:

def suite():
    suite = unittest.TestSuite()
    suite.addTest(WidgetTestCase('test_default_widget_size'))
    suite.addTest(WidgetTestCase('test_widget_resize'))
    return suite

if __name__ == '__main__':
    runner = unittest.TextTestRunner()
    runner.run(suite())

Du kan placera definitionerna av testfall och testsviter i samma moduler som den kod de ska testa (t.ex. widget.py), men det finns flera fördelar med att placera testkoden i en separat modul, t.ex. test_widget.py:

Testmodulen kan köras fristående från kommandoraden.
Testkoden kan lättare separeras från den levererade koden.
Det är mindre frestande att utan goda skäl ändra testkoden så att den passar den kod som testas.
Testkod bör modifieras mycket mer sällan än den kod som den testar.
Testad kod kan lättare omarbetas.
Tester för moduler som är skrivna i C måste ändå vara i separata moduler, så varför inte vara konsekvent?
Om teststrategin ändras behöver källkoden inte ändras.

Återanvändning av gammal testkod¶

Vissa användare kommer att upptäcka att de har befintlig testkod som de vill köra från unittest, utan att konvertera varje gammal testfunktion till en TestCase-underklass.

Av denna anledning tillhandahåller unittest en FunctionTestCase-klass. Denna subklass av TestCase kan användas för att paketera en befintlig testfunktion. Funktioner för uppbyggnad och nedmontering kan också tillhandahållas.

Givet följande testfunktion:

def testSomething():
    something = makeSomething()
    assert something.name is not None
    # ...

kan man skapa en motsvarande testfallsinstans på följande sätt, med valfria metoder för uppbyggnad och nedmontering:

testcase = unittest.FunctionTestCase(testSomething,
                                     setUp=makeSomethingDB,
                                     tearDown=deleteSomethingDB)

Anteckning

Även om FunctionTestCase kan användas för att snabbt konvertera en befintlig testbas till ett unittest -baserat system, rekommenderas inte detta tillvägagångssätt. Att ta sig tid att skapa korrekta TestCase-subklasser kommer att göra framtida refaktoriseringar av tester oändligt mycket enklare.

I vissa fall kan de befintliga testerna ha skrivits med modulen doctest. Om så är fallet tillhandahåller doctest en DocTestSuite-klass som automatiskt kan bygga unittest.TestSuite-instanser från de befintliga doctest-baserade testerna.

Skippa tester och förväntade misslyckanden¶

Tillagd i version 3.1.

Unittest har stöd för att hoppa över enskilda testmetoder och till och med hela klasser av tester. Dessutom finns det stöd för att markera ett test som ett ”förväntat misslyckande”, ett test som är trasigt och kommer att misslyckas, men som inte bör räknas som ett misslyckande i TestResult.

Att hoppa över ett test är helt enkelt en fråga om att använda skip() decorator eller en av dess villkorliga varianter, anropa TestCase.skipTest() inom en setUp() eller testmetod, eller att direkt ställa in SkipTest.

Grundläggande hoppning ser ut så här:

class MyTestCase(unittest.TestCase):

    @unittest.skip("demonstrating skipping")
    def test_nothing(self):
        self.fail("shouldn't happen")

    @unittest.skipIf(mylib.__version__ < (1, 3),
                     "not supported in this library version")
    def test_format(self):
        # Tests that work for only a certain version of the library.
        pass

    @unittest.skipUnless(sys.platform.startswith("win"), "requires Windows")
    def test_windows_support(self):
        # windows specific testing code
        pass

    def test_maybe_skipped(self):
        if not external_resource_available():
            self.skipTest("external resource not available")
        # test code that depends on the external resource
        pass

Så här ser resultatet ut när du kör exemplet ovan i verbose-läge:

test_format (__main__.MyTestCase.test_format) ... skipped 'not supported in this library version'
test_nothing (__main__.MyTestCase.test_nothing) ... skipped 'demonstrating skipping'
test_maybe_skipped (__main__.MyTestCase.test_maybe_skipped) ... skipped 'external resource not available'
test_windows_support (__main__.MyTestCase.test_windows_support) ... skipped 'requires Windows'

----------------------------------------------------------------------
Ran 4 tests in 0.005s

OK (skipped=4)

Klasser kan hoppas över precis som metoder:

@unittest.skip("visar klasshoppning")
klass MySkippedTestCase(unittest.TestCase):
    def test_not_run(self):
        passera

TestCase.setUp() kan också hoppa över testet. Detta är användbart när en resurs som behöver konfigureras inte är tillgänglig.

Förväntade fel använder dekoratorn expectedFailure().

class ExpectedFailureTestCase(unittest.TestCase):
    @unittest.expectedFailure
    def test_fail(self):
        self.assertEqual(1, 0, "broken")

Det är enkelt att skapa egna dekoratorer för att hoppa över tester genom att skapa en dekorator som anropar skip() på testet när den vill att det ska hoppas över. Denna dekorator hoppar över testet om inte det passerade objektet har ett visst attribut:

def skipUnlessHasattr(obj, attr):
    if hasattr(obj, attr):
        return lambda func: func
    return unittest.skip("{!r} har inte {!r}".format(obj, attr))

Följande dekoratorer och undantag implementerar testöverhoppning och förväntade fel:

@unittest.skip(reason)¶: Hoppa ovillkorligen över det dekorerade testet. reason bör beskriva varför testet hoppas över.

@unittest.skipIf(condition, reason)¶: Hoppa över det dekorerade testet om villkoret är sant.

@unittest.skipUnless(condition, reason)¶: Hoppa över det dekorerade testet om inte villkoret är sant.

@unittest.expectedFailure¶: Markera testet som ett förväntat misslyckande eller fel. Om testet misslyckas eller fel uppstår i själva testfunktionen (snarare än i någon av metoderna i test fixture) kommer det att betraktas som en framgång. Om testet godkänns kommer det att betraktas som ett misslyckande.

exception unittest.SkipTest(reason)¶

Detta undantag görs för att hoppa över ett test.

Vanligtvis kan du använda TestCase.skipTest() eller någon av dekoratorerna för att hoppa över istället för att ta upp detta direkt.

Överhoppade tester kommer inte att ha setUp() eller tearDown() körda runt dem. Överhoppade klasser kommer inte att ha setUpClass() eller tearDownClass() körda. Överhoppade moduler kommer inte att få setUpModule() eller tearDownModule() körda.

Särskiljande av testiterationer med hjälp av deltest¶

Tillagd i version 3.4.

När det finns mycket små skillnader mellan dina tester, t.ex. några parametrar, kan du med unittest skilja dem åt inuti en testmetod med hjälp av kontexthanteraren subTest().

Till exempel följande test:

class NumbersTest(unittest.TestCase):

    def test_even(self):
        """
        Test that numbers between 0 and 5 are all even.
        """
        for i in range(0, 6):
            with self.subTest(i=i):
                self.assertEqual(i % 2, 0)

kommer att ge följande utdata:

======================================================================
FAIL: test_even (__main__.NumbersTest.test_even) (i=1)
Testar att alla tal mellan 0 och 5 är jämna.
----------------------------------------------------------------------
Traceback (senaste anropet senast):
  Fil "subtests.py", rad 11, i test_even
    self.assertEqual(i % 2, 0)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 1 != 0

======================================================================
FAIL: test_even (__main__.NumbersTest.test_even) (i=3)
Testar att alla tal mellan 0 och 5 är jämna.
----------------------------------------------------------------------
Traceback (senaste anropet senast):
  Fil "subtests.py", rad 11, i test_even
    self.assertEqual(i % 2, 0)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 1 != 0

======================================================================
FAIL: test_even (__main__.NumbersTest.test_even) (i=5)
Testar att alla tal mellan 0 och 5 är jämna.
----------------------------------------------------------------------
Traceback (senaste anropet senast):
  Fil "subtests.py", rad 11, i test_even
    self.assertEqual(i % 2, 0)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 1 != 0

Utan att använda ett deltest skulle exekveringen avbrytas efter det första felet, och felet skulle vara svårare att diagnostisera eftersom värdet på i inte skulle visas:

======================================================================
FAIL: test_even (__main__.NumbersTest.test_even)
----------------------------------------------------------------------
Traceback (senaste anropet senast):
  Fil "subtests.py", rad 32, i test_even
    self.assertEqual(i % 2, 0)
AssertionError (påståendefel): 1 != 0

Klasser och funktioner¶

I det här avsnittet beskrivs API:et för unittest på ett djupgående sätt.

Testfall¶

class unittest.TestCase(methodName='runTest')¶

Instanser av klassen TestCase representerar de logiska testenheterna i unittest-universumet. Den här klassen är avsedd att användas som basklass, där specifika tester implementeras av konkreta underklasser. Den här klassen implementerar det gränssnitt som testköraren behöver för att kunna köra testerna, och metoder som testkoden kan använda för att kontrollera och rapportera olika typer av fel.

Varje instans av TestCase kommer att köra en enda basmetod: metoden med namnet methodName. I de flesta användningar av TestCase kommer du varken att ändra methodName eller återimplementera standardmetoden runTest().

Ändrad i version 3.2: TestCase kan instansieras framgångsrikt utan att ange ett methodName. Detta gör det lättare att experimentera med TestCase från den interaktiva tolken.

TestCase-instanser tillhandahåller tre grupper av metoder: en grupp som används för att köra testet, en annan som används av testimplementeringen för att kontrollera villkor och rapportera fel, och några undersökningsmetoder som gör det möjligt att samla in information om själva testet.

Metoder i den första gruppen (som kör testet) är:

setUp()¶: Metod som anropas för att förbereda testfixturen. Den anropas omedelbart innan testmetoden anropas; förutom AssertionError eller SkipTest kommer alla undantag som denna metod ger upphov till att betraktas som fel snarare än som ett misslyckat test. Standardimplementationen gör ingenting.

tearDown()¶: Metod som anropas omedelbart efter att testmetoden har anropats och resultatet registrerats. Denna metod anropas även om testmetoden gav upphov till ett undantag, så implementeringen i underklasser kan behöva vara särskilt noggrann med att kontrollera det interna tillståndet. Varje undantag, annat än AssertionError eller SkipTest, som anropas av denna metod kommer att betraktas som ett ytterligare fel snarare än ett misslyckat test (vilket ökar det totala antalet rapporterade fel). Denna metod kommer endast att anropas om setUp() lyckas, oavsett resultatet av testmetoden. Standardimplementeringen gör ingenting.

setUpClass()¶

En klassmetod som anropas innan tester i en enskild klass körs. setUpClass anropas med klassen som enda argument och måste vara dekorerad som en classmethod():

@classmethod
def setUpClass(cls):
    ...

Se Klass- och modulfixturer för mer information.

Tillagd i version 3.2.

tearDownClass()¶

En klassmetod som anropas efter att testerna i en enskild klass har körts. tearDownClass anropas med klassen som enda argument och måste vara dekorerad som en classmethod():

@classmethod
def tearDownClass(cls):
    ...

Se Klass- och modulfixturer för mer information.

Tillagd i version 3.2.

run(result=None)¶

Kör testet och samla in resultatet i TestResult-objektet som skickas som result. Om result utelämnas eller är None skapas ett temporärt resultatobjekt (genom att anropa metoden defaultTestResult()) och används. Resultatobjektet returneras till run():s anropare.

Samma effekt kan uppnås genom att helt enkelt anropa TestCase-instansen.

Ändrad i version 3.3: Tidigare versioner av run returnerade inte resultatet. Inte heller att anropa en instans.

skipTest(reason)¶: Om du anropar detta under en testmetod eller setUp() hoppar du över det aktuella testet. Se Skippa tester och förväntade misslyckanden för mer information.

Tillagd i version 3.1.

subTest(msg=None, **params)¶

Returnerar en kontexthanterare som exekverar det bifogade kodblocket som ett subtest. msg och params är valfria, godtyckliga värden som visas när ett deltest misslyckas, vilket gör att du kan identifiera dem tydligt.

Ett testfall kan innehålla ett obegränsat antal subtestdeklarationer, och de kan vara godtyckligt nästlade.

Se Särskiljande av testiterationer med hjälp av deltest för mer information.

Tillagd i version 3.4.

debug()¶: Kör testet utan att samla in resultatet. Detta gör att undantag som uppstår i testet kan vidarebefordras till den som anropar och kan användas för att köra tester under en debugger.

Klassen TestCase innehåller flera assert-metoder för att kontrollera och rapportera fel. I följande tabell listas de vanligaste metoderna (se tabellerna nedan för fler assert-metoder):

Metod	Kontrollerar att	Ny i
`assertEqual(a, b)`	`a == b`
`assertNotEqual(a, b)`	`a != b`
`assertTrue(x)`	`bool(x) is True`
`assertFalse(x)`	`bool(x) is False`
`assertIs(a, b)`	`a is b`	3.1
`assertIsNot(a, b)`	`a is not b`	3.1
`assertIsNone(x)`	`x is None`	3.1
`assertIsNotNone(x)`	`x is not None`	3.1
`assertIn(a, b)`	`a in b`	3.1
`assertNotIn(a, b)`	`a not in b`	3.1
`assertIsInstance(a, b)`	`isinstance(a, b)`	3.2
`assertNotIsInstance(a, b)`	`not isinstance(a, b)`	3.2
`assertIsSubclass(a, b)`	`issubclass(a, b)`	3.14
`assertNotIsSubclass(a, b)`	`not issubclass(a, b)`	3.14

Alla assert-metoder accepterar ett msg-argument som, om det anges, används som felmeddelande vid misslyckande (se även longMessage). Observera att nyckelordsargumentet msg endast kan skickas till assertRaises(), assertRaisesRegex(), assertWarns(), assertWarnsRegex() när de används som kontexthanterare.

assertEqual(first, second, msg=None)¶

Testa att first och second är lika stora. Om värdena inte jämförs lika kommer testet att misslyckas.

Dessutom, om first och second är exakt samma typ och en av list, tuple, dict, set, frozenset eller str eller någon typ som en underklass registrerar med addTypeEqualityFunc() kommer den typspecifika likhetsfunktionen att anropas för att generera ett mer användbart standardfelmeddelande (se även list of type-specific methods).

Ändrad i version 3.1: Lagt till automatisk anrop av typspecifik likhetsfunktion.

Ändrad i version 3.2: assertMultiLineEqual() tillagd som standardfunktion för typjämförelse för jämförelse av strängar.

assertNotEqual(first, second, msg=None)¶: Testa att first och second inte är lika. Om värdena är lika med varandra kommer testet att misslyckas.

assertTrue(expr, msg=None)¶

assertFalse(expr, msg=None)¶

Testa att expr är sant (eller falskt).

Observera att detta är likvärdigt med bool(expr) is True och inte med expr is True (använd assertIs(expr, True) för det senare). Denna metod bör också undvikas när mer specifika metoder finns tillgängliga (t.ex. assertEqual(a, b) istället för assertTrue(a == b)), eftersom de ger ett bättre felmeddelande vid fel.

assertIs(first, second, msg=None)¶
assertIsNot(first, second, msg=None)¶: Testa att first och second är (eller inte är) samma objekt.

Tillagd i version 3.1.

assertIsNone(expr, msg=None)¶
assertIsNotNone(expr, msg=None)¶: Testa att expr är (eller inte är) None.

Tillagd i version 3.1.

assertIn(member, container, msg=None)¶
assertNotIn(member, container, msg=None)¶: Testa att member är (eller inte är) i container.

Tillagd i version 3.1.

assertIsInstance(obj, cls, msg=None)¶
assertNotIsInstance(obj, cls, msg=None)¶: Testa att obj är (eller inte är) en instans av cls (som kan vara en klass eller en tupel av klasser, vilket stöds av isinstance()). För att kontrollera den exakta typen, använd assertIs(type(obj), cls).

Tillagd i version 3.2.

assertIsSubclass(cls, superclass, msg=None)¶
assertNotIsSubclass(cls, superclass, msg=None)¶: Testa att cls är (eller inte är) en underklass till superclass (som kan vara en klass eller en tupel av klasser, vilket stöds av issubclass()). För att kontrollera den exakta typen, använd assertIs(cls, superclass).

Tillagd i version 3.14.

Det är också möjligt att kontrollera produktionen av undantag, varningar och loggmeddelanden med hjälp av följande metoder:

Metod	Kontrollerar att	Ny i
`assertRaises(exc, fun, args, *kwds)`	`fun(args, kwds)` ger upphov till exc*
`assertRaisesRegex(exc, r, fun, args, *kwds)`	`fun(args, kwds)` ger upphov till exc* och meddelandet matchar regex r	3.1
`assertWarns(warn, fun, args, *kwds)`	`fun(args, kwds)` ger upphov till varning*	3.2
`assertWarnsRegex(warn, r, fun, args, *kwds)`	`fun(args, kwds)` ger upphov till warn* och meddelandet matchar regex r	3.2
`assertLogs(logger, level)`	Blocket `with` loggar på logger med lägsta nivå	3.4
`assertNoLogs(logger, level)`	Blocket `with` loggar inte in logger med lägsta nivå	3.10

assertRaises(exception, callable, *args, **kwds)¶

assertRaises(exception, *, msg=None)

Testar att ett undantag utlöses när callable anropas med eventuella positionella eller nyckelordsargument som också skickas till assertRaises(). Testet godkänns om exception utlöses, är ett fel om ett annat undantag utlöses eller misslyckas om inget undantag utlöses. För att fånga upp något av en grupp undantag kan en tupel som innehåller undantagsklasserna skickas som exception.

Om endast argumenten exception och eventuellt msg anges, returneras en kontexthanterare så att koden som testas kan skrivas inline i stället för som en funktion:

with self.assertRaises(SomeException):
    do_something()

När den används som kontexthanterare accepterar assertRaises() det extra nyckelordsargumentet msg.

Kontexthanteraren lagrar det fångade undantagsobjektet i dess exception-attribut. Detta kan vara användbart om avsikten är att utföra ytterligare kontroller på det undantag som uppstått:

med self.assertRaises(SomeException) som cm:
    gör_något()

the_exception = cm.undantag
self.assertEqual(the_exception.error_code, 3)

Ändrad i version 3.1: Lagt till möjligheten att använda assertRaises() som en kontexthanterare.

Ändrad i version 3.2: Lagt till attributet exception.

Ändrad i version 3.3: Lagt till nyckelordsargumentet msg när det används som en kontexthanterare.

assertRaisesRegex(exception, regex, callable, *args, **kwds)¶

assertRaisesRegex(exception, regex, *, msg=None)

Som assertRaises() men testar också att regex matchar strängrepresentationen av det undantag som uppstod. regex kan vara ett objekt för reguljära uttryck eller en sträng som innehåller ett reguljärt uttryck som är lämpligt för användning av re.search(). Exempel:

self.assertRaisesRegex(ValueError,"ogiltig bokstav för.*XYZ'$",
                       int, 'XYZ')

eller:

med self.assertRaisesRegex(ValueError, 'literal'):
   int('XYZ')

Tillagd i version 3.1: Tillagd under namnet assertRaisesRegexp.

Ändrad i version 3.2: Omdöpta till assertRaisesRegex().

Ändrad i version 3.3: Lagt till nyckelordsargumentet msg när det används som en kontexthanterare.

assertWarns(warning, callable, *args, **kwds)¶

assertWarns(warning, *, msg=None)

Testar att en varning utlöses när callable anropas med positionella eller nyckelordsargument som också skickas till assertWarns(). Testet godkänns om warning utlöses och misslyckas om så inte är fallet. Varje undantag är ett fel. För att fånga någon av en grupp varningar kan en tupel som innehåller varningsklasserna skickas som warnings.

Om endast argumenten warning och eventuellt msg anges, returneras en kontexthanterare så att koden som testas kan skrivas inline i stället för som en funktion:

with self.assertWarns(SomeWarning):
    do_something()

När assertWarns() används som en kontexthanterare accepteras det extra nyckelordsargumentet msg.

Kontexthanteraren lagrar det fångade varningsobjektet i attributet warning och källraden som utlöste varningarna i attributen filename och lineno. Detta kan vara användbart om avsikten är att utföra ytterligare kontroller på den fångade varningen:

with self.assertWarns(SomeWarning) as cm:
    do_something()

self.assertIn('myfile.py', cm.filename)
self.assertEqual(320, cm.lineno)

Denna metod fungerar oavsett vilka varningsfilter som finns på plats när den anropas.

Tillagd i version 3.2.

Ändrad i version 3.3: Lagt till nyckelordsargumentet msg när det används som en kontexthanterare.

assertWarnsRegex(warning, regex, callable, *args, **kwds)¶

assertWarnsRegex(warning, regex, *, msg=None)

Som assertWarns() men testar också att regex matchar meddelandet i den utlösta varningen. regex kan vara ett objekt för reguljära uttryck eller en sträng som innehåller ett reguljärt uttryck som är lämpligt för användning av re.search(). Exempel:

self.assertWarnsRegex(DeprecationWarning,
                      r'legacy_function\(\) is deprecated',
                      legacy_function, 'XYZ')

eller:

with self.assertWarnsRegex(RuntimeWarning, 'unsafe frobnicating'):
    frobnicate('/etc/passwd')

Tillagd i version 3.2.

Ändrad i version 3.3: Lagt till nyckelordsargumentet msg när det används som en kontexthanterare.

assertLogs(logger=None, level=None)¶

En kontexthanterare som testar att minst ett meddelande loggas på logger eller ett av dess barn, med minst den angivna level.

Om logger anges ska det vara ett logging.Logger-objekt eller ett str som anger namnet på en logger. Standard är rotloggern, som fångar upp alla meddelanden som inte blockerats av en icke-propagerande logger i nedstigande led.

Om level anges ska det vara antingen en numerisk loggningsnivå eller dess strängmotsvarighet (t.ex. antingen "ERROR" eller logging.ERROR). Standardvärdet är logging.INFO.

Testet godkänns om minst ett meddelande som sänds ut i with-blocket uppfyller villkoren logger och level, annars misslyckas det.

Objektet som returneras av kontexthanteraren är en inspelningshjälp som håller reda på de matchande loggmeddelandena. Det har två attribut:

records¶: En lista med logging.LogRecord-objekt för de matchande loggmeddelandena.

output¶: En lista med str-objekt med formaterade utdata från matchande meddelanden.

Exempel:

med self.assertLogs('foo', level='INFO') som cm:
    logging.getLogger('foo').info('första meddelandet')
    logging.getLogger('foo.bar').error('andra meddelandet')
self.assertEqual(cm.output, ['INFO:foo:första meddelandet',
                             'ERROR:foo.bar:andra meddelandet'])

Tillagd i version 3.4.

assertNoLogs(logger=None, level=None)¶

En kontexthanterare som testar att inga meddelanden loggas på logger eller ett av dess underordnade objekt, med minst den angivna level.

Om logger anges ska det vara ett logging.Logger-objekt eller ett str som anger namnet på en logger. Standard är rotloggaren, som fångar upp alla meddelanden.

Om level anges ska det vara antingen en numerisk loggningsnivå eller dess strängmotsvarighet (t.ex. antingen "ERROR" eller logging.ERROR). Standardvärdet är logging.INFO.

Till skillnad från assertLogs() kommer inget att returneras av kontexthanteraren.

Tillagd i version 3.10.

Det finns också andra metoder som används för att utföra mer specifika kontroller, t.ex:

Metod	Kontrollerar att	Ny i
`assertAlmostEqual(a, b)`	`round(a-b, 7) == 0`
`assertNotAlmostEqual(a, b)`	`round(a-b, 7) != 0`
`assertGreater(a, b)`	`a > b`	3.1
`assertGreaterEqual(a, b)`	`a >= b`	3.1
`assertLess(a, b)`	`a < b`	3.1
`assertLessEqual(a, b)`	`a <= b`	3.1
`assertRegex(s, r)`	`r.search(s)`	3.1
`assertNotRegex(s, r)`	`inte r.sök(s)`	3.2
`assertCountEqual(a, b)`	a och b har samma element i samma antal, oberoende av deras ordning.	3.2
`assertStartsWith(a, b)`	`a.startswith(b)`	3.14
`assertNotStartsWith(a, b)`	`not a.startswith(b)`	3.14
`assertEndsWith(a, b)`	`a.endswith(b)`	3.14
`assertNotEndsWith(a, b)`	`not a.endswith(b)`	3.14
`assertHasAttr(a, b)`	`hastattr(a, b)`	3.14
`assertNotHasAttr(a, b)`	`not hastattr(a, b)`	3.14

assertAlmostEqual(first, second, places=7, msg=None, delta=None)¶

assertNotAlmostEqual(first, second, places=7, msg=None, delta=None)¶

Testa att first och second är ungefär (eller inte ungefär) lika genom att beräkna skillnaden, avrunda till det angivna antalet decimaler (standard 7) och jämföra med noll. Observera att dessa metoder avrundar värdena till det angivna antalet decimaler (dvs. som funktionen round()) och inte till signifikanta siffror.

Om delta anges i stället för places måste skillnaden mellan first och second vara mindre eller lika med (eller större än) delta.

Att ange både delta och places ger upphov till ett TypeError.

Ändrad i version 3.2: assertAlmostEqual() betraktar automatiskt nästan lika objekt som jämför lika. assertNotAlmostEqual() misslyckas automatiskt om objekten jämför lika. Lade till nyckelordsargumentet delta.

assertGreater(first, second, msg=None)¶

assertGreaterEqual(first, second, msg=None)¶

assertLess(first, second, msg=None)¶

assertLessEqual(first, second, msg=None)¶

Testar att first är >, >=, < eller <= än second beroende på metodnamnet. Om inte, kommer testet att misslyckas:

>>> self.assertGreaterEqual(3, 4)
AssertionError: "3" unexpectedly not greater than or equal to "4"

Tillagd i version 3.1.

assertRegex(text, regex, msg=None)¶
assertNotRegex(text, regex, msg=None)¶: Testar att en regex-sökning matchar (eller inte matchar) text. Om sökningen misslyckas kommer felmeddelandet att innehålla mönstret och text (eller mönstret och den del av text som oväntat matchade). regex kan vara ett objekt för reguljära uttryck eller en sträng som innehåller ett reguljärt uttryck som är lämpligt för användning av re.search().

Tillagd i version 3.1: Tillagd under namnet assertRegexpMatches.

Ändrad i version 3.2: Metoden assertRegexpMatches() har bytt namn till assertRegex().

Tillagd i version 3.2: assertNotRegex().

assertCountEqual(first, second, msg=None)¶

Testa att sekvensen först innehåller samma element som andra, oavsett deras ordning. Om de inte gör det genereras ett felmeddelande som listar skillnaderna mellan sekvenserna.

Duplicerade element ignoreras inte vid jämförelse av första och andra. Det kontrolleras om varje element har samma antal i båda sekvenserna. Likvärdig med: assertEqual(Counter(list(first)), Counter(list(second))) men fungerar även med sekvenser av icke-hashbara objekt.

Tillagd i version 3.2.

assertStartsWith(s, prefix, msg=None)¶

assertNotStartsWith(s, prefix, msg=None)¶: Testar att Unicode- eller byte-strängen s börjar (eller inte börjar) med ett prefix. prefix kan också vara en tupel av strängar som ska testas.

Tillagd i version 3.14.

assertEndsWith(s, suffix, msg=None)¶

assertNotEndsWith(s, suffix, msg=None)¶: Testar att Unicode- eller byte-strängen s slutar (eller inte slutar) med ett suffix. suffix kan också vara en tupel av strängar som ska testas.

Tillagd i version 3.14.

assertHasAttr(obj, name, msg=None)¶

assertNotHasAttr(obj, name, msg=None)¶: Testar att objektet obj har (eller inte har) ett attribut name.

Tillagd i version 3.14.

Metoden assertEqual() skickar jämlikhetskontrollen för objekt av samma typ till olika typspecifika metoder. Dessa metoder är redan implementerade för de flesta av de inbyggda typerna, men det är också möjligt att registrera nya metoder med addTypeEqualityFunc():

addTypeEqualityFunc(typeobj, function)¶: Registrerar en typspecifik metod som anropas av assertEqual() för att kontrollera om två objekt av exakt samma typobj (inte underklasser) är lika. function måste ta två positionella argument och ett tredje msg=None nyckelordsargument precis som assertEqual() gör. Den måste ge upphov till self.failureException(msg) när ojämlikhet mellan de två första parametrarna upptäcks – eventuellt ge användbar information och förklara ojämlikheterna i detalj i felmeddelandet.

Tillagd i version 3.1.

Listan över typspecifika metoder som automatiskt används av assertEqual() sammanfattas i följande tabell. Observera att det vanligtvis inte är nödvändigt att anropa dessa metoder direkt.

Metod	Används för att jämföra	Ny i
`assertMultiLineEqual(a, b)`	strängar	3.1
`assertSequenceEqual(a, b)`	sekvenser	3.1
`assertListEqual(a, b)`	listor	3.1
`assertTupleEqual(a, b)`	tupler	3.1
`assertSetEqual(a, b)`	uppsättningar eller frozensets	3.1
`assertDictEqual(a, b)`	dikter	3.1

assertMultiLineEqual(first, second, msg=None)¶: Testa att den flerradiga strängen first är lika med strängen second. Om strängarna inte är lika kommer en diff av de två strängarna som belyser skillnaderna att inkluderas i felmeddelandet. Den här metoden används som standard när strängar jämförs med assertEqual().

Tillagd i version 3.1.

assertSequenceEqual(first, second, msg=None, seq_type=None)¶

Testar att två sekvenser är lika. Om en seq_type anges måste både first och second vara instanser av seq_type, annars uppstår ett fel. Om sekvenserna är olika konstrueras ett felmeddelande som visar skillnaden mellan de två.

Denna metod anropas inte direkt av assertEqual(), men den används för att implementera assertListEqual() och assertTupleEqual().

Tillagd i version 3.1.

assertListEqual(first, second, msg=None)¶
assertTupleEqual(first, second, msg=None)¶: Testar att två listor eller tupler är lika. Om så inte är fallet konstrueras ett felmeddelande som endast visar skillnaderna mellan de två. Ett felmeddelande visas också om någon av parametrarna är av fel typ. Dessa metoder används som standard när listor eller tupler jämförs med assertEqual().

Tillagd i version 3.1.

assertSetEqual(first, second, msg=None)¶

Testar att två uppsättningar är lika. Om inte, konstrueras ett felmeddelande som listar skillnaderna mellan uppsättningarna. Den här metoden används som standard när man jämför uppsättningar eller frozensets med assertEqual().

Misslyckas om first eller second inte har någon set.difference()-metod.

Tillagd i version 3.1.

assertDictEqual(first, second, msg=None)¶: Testa att två ordböcker är likvärdiga. Om inte, konstrueras ett felmeddelande som visar skillnaderna i ordböckerna. Denna metod kommer att användas som standard för att jämföra ordböcker i anrop till assertEqual().

Tillagd i version 3.1.

Slutligen tillhandahåller TestCase följande metoder och attribut:

fail(msg=None)¶: Signalerar ovillkorligt att testet misslyckats, med msg eller None som felmeddelande.

failureException¶: Detta klassattribut anger det undantag som testmetoden ger upphov till. Om ett testramverk behöver använda ett specialiserat undantag, eventuellt för att bära ytterligare information, måste det underklassa detta undantag för att ”spela rättvist” med ramverket. Det initiala värdet för detta attribut är AssertionError.

longMessage¶

Detta klassattribut avgör vad som händer när ett anpassat felmeddelande skickas som msg-argument till ett assertXYY-anrop som misslyckas. True är standardvärdet. I det här fallet läggs det anpassade meddelandet till i slutet av standardmeddelandet om misslyckande. När värdet är satt till False ersätter det anpassade meddelandet standardmeddelandet.

Klassinställningen kan åsidosättas i enskilda testmetoder genom att tilldela ett instansattribut, self.longMessage, till True eller False innan assert-metoderna anropas.

Klassinställningen återställs före varje testanrop.

Tillagd i version 3.1.

maxDiff¶

Detta attribut styr den maximala längden på differenser som skrivs ut av assert-metoder som rapporterar differenser vid fel. Standardvärdet är 80*8 tecken. Assert-metoder som påverkas av detta attribut är assertSequenceEqual() (inklusive alla sekvensjämförelsemetoder som delegeras till den), assertDictEqual() och assertMultiLineEqual().

Om du anger maxDiff till None innebär det att det inte finns någon maximal längd på diffar.

Tillagd i version 3.2.

Testramverk kan använda följande metoder för att samla in information om testet:

countTestCases()¶: Returnerar antalet tester som representeras av detta testobjekt. För TestCase-instanser kommer detta alltid att vara 1.

defaultTestResult()¶

Returnerar en instans av den testresultatklass som ska användas för denna testfallsklass (om ingen annan resultatinstans har angetts för run()-metoden).

För TestCase-instanser kommer detta alltid att vara en instans av TestResult; underklasser till TestCase bör åsidosätta detta vid behov.

id()¶: Returnerar en sträng som identifierar det specifika testfallet. Detta är vanligtvis det fullständiga namnet på testmetoden, inklusive modul- och klassnamnet.

shortDescription()¶: Returnerar en beskrivning av testet, eller None om ingen beskrivning har angetts. Standardimplementeringen av denna metod returnerar den första raden i testmetodens dokumentsträng, om den finns tillgänglig, eller None.

Ändrad i version 3.1: I 3.1 ändrades detta så att testnamnet lades till i den korta beskrivningen även om det fanns en docstring. Detta orsakade kompatibilitetsproblem med unittest-tillägg och tillägget av testnamnet flyttades till TextTestResult i Python 3.2.

addCleanup(function, /, *args, **kwargs)¶

Lägg till en funktion som ska anropas efter tearDown() för att rensa resurser som använts under testet. Funktioner kommer att anropas i omvänd ordning mot den ordning de läggs till (LIFO). De anropas med alla argument och nyckelordsargument som skickas in i addCleanup() när de läggs till.

Om setUp() misslyckas, vilket innebär att tearDown() inte anropas, anropas ändå eventuella cleanup-funktioner som lagts till.

Tillagd i version 3.1.

enterContext(cm)¶: Ange den medföljande context manager. Om det lyckas, lägg också till dess __exit__()-metod som en uppstädningsfunktion med addCleanup() och returnera resultatet av __enter__()-metoden.

Tillagd i version 3.11.

doCleanups()¶

Denna metod anropas ovillkorligen efter tearDown(), eller efter setUp() om setUp() ger upphov till ett undantag.

Den är ansvarig för att anropa alla upprensningsfunktioner som lagts till av addCleanup(). Om du vill att rensningsfunktionerna ska anropas före tearDown() kan du anropa doCleanups() själv.

doCleanups() plockar metoder från stacken med rensningsfunktioner en i taget, så att den kan anropas när som helst.

Tillagd i version 3.1.

classmethod addClassCleanup(function, /, *args, **kwargs)¶

Lägg till en funktion som ska anropas efter tearDownClass() för att städa upp resurser som använts under testklassen. Funktioner kommer att anropas i omvänd ordning mot den ordning de läggs till (LIFO). De anropas med alla argument och nyckelordsargument som skickas in i addClassCleanup() när de läggs till.

Om setUpClass() misslyckas, vilket innebär att tearDownClass() inte anropas, så kommer eventuella cleanup-funktioner som lagts till ändå att anropas.

Tillagd i version 3.8.

classmethod enterClassContext(cm)¶: Ange den medföljande context manager. Om det lyckas, lägg också till dess __exit__()-metod som en uppstädningsfunktion med addClassCleanup() och returnera resultatet av __enter__()-metoden.

Tillagd i version 3.11.

classmethod doClassCleanups()¶

Denna metod anropas ovillkorligen efter tearDownClass(), eller efter setUpClass() om setUpClass() ger upphov till ett undantag.

Den är ansvarig för att anropa alla uppstädningsfunktioner som lagts till av addClassCleanup(). Om du vill att rensningsfunktionerna ska anropas före tearDownClass() kan du själv anropa doClassCleanups().

doClassCleanups() plockar bort metoder från stacken med rensningsfunktioner en i taget, så att den kan anropas när som helst.

Tillagd i version 3.8.

class unittest.IsolatedAsyncioTestCase(methodName='runTest')¶

Denna klass tillhandahåller ett API som liknar TestCase och accepterar även coroutines som testfunktioner.

Tillagd i version 3.8.

loop_factory¶: Den loop_factory som skickas till asyncio.Runner. Åsidosätt i underklasser med asyncio.EventLoop för att undvika att använda asyncios policysystem.

Tillagd i version 3.13.

async asyncSetUp()¶: Metod som anropas för att förbereda testfixturen. Detta anropas efter setUp(). Detta anropas omedelbart innan testmetoden anropas; förutom AssertionError eller SkipTest, kommer alla undantag som denna metod ger upphov till att betraktas som ett fel snarare än ett misslyckat test. Standardimplementationen gör ingenting.

async asyncTearDown()¶: Metod som anropas omedelbart efter att testmetoden har anropats och resultatet registrerats. Detta anropas före tearDown(). Den anropas även om testmetoden gav upphov till ett undantag, så implementeringen i underklasser kan behöva vara särskilt noggrann med att kontrollera det interna tillståndet. Varje undantag, annat än AssertionError eller SkipTest, som anropas av denna metod kommer att betraktas som ett ytterligare fel snarare än ett testfel (vilket ökar det totala antalet rapporterade fel). Denna metod kommer endast att anropas om asyncSetUp() lyckas, oavsett resultatet av testmetoden. Standardimplementeringen gör ingenting.

addAsyncCleanup(function, /, *args, **kwargs)¶: Den här metoden accepterar en coroutine som kan användas som en rensningsfunktion.

async enterAsyncContext(cm)¶: Ange den medföljande asynchronous context manager. Om det lyckas, lägg också till dess __aexit__()-metod som en uppstädningsfunktion med addAsyncCleanup() och returnera resultatet av __aenter__()-metoden.

Tillagd i version 3.11.

run(result=None)¶: Skapar en ny händelseslinga för att köra testet och samlar in resultatet i TestResult-objektet som skickas som result. Om result utelämnas eller är None skapas ett temporärt resultatobjekt (genom att anropa metoden defaultTestResult()) och används. Resultatobjektet returneras till run():s anropare. I slutet av testet avbryts alla uppgifter i händelseslingan.

Ett exempel som illustrerar ordningen:

from unittest import IsolatedAsyncioTestCase

händelser = []


klass Test(IsolatedAsyncioTestCase):


    def setUp(self):
        events.append("setUp")

    async def asyncSetUp(self):
        self._async_connection = await AsyncConnection()
        events.append("asyncSetUp")

    async def test_response(self):
        events.append("test_response")
        response = await self._async_connection.get("https://example.com")
        self.assertEqual(svar.status_kod, 200)
        self.addAsyncCleanup(self.on_cleanup)

    def tearDown(self):
        events.append("tearDown")

    async def asyncTearDown(self):
        await self._async_connection.close()
        events.append("asyncTearDown")

    async def on_cleanup(self):
        events.append("cleanup")

om __name__ == "__main__":
    unittest.main()

Efter att testet körts skulle events innehålla ["setUp", "asyncSetUp", "test_response", "asyncTearDown", "tearDown", "cleanup"].

class unittest.FunctionTestCase(testFunc, setUp=None, tearDown=None, description=None)¶: Denna klass implementerar den del av TestCase-gränssnittet som gör det möjligt för testköraren att köra testet, men tillhandahåller inte de metoder som testkoden kan använda för att kontrollera och rapportera fel. Detta används för att skapa testfall med hjälp av äldre testkod, vilket gör att den kan integreras i ett unittest-baserat testramverk.

Gruppering av tester¶

class unittest.TestSuite(tests=())¶

Denna klass representerar en sammanställning av enskilda testfall och testsviter. Klassen presenterar det gränssnitt som testlöparen behöver för att kunna köra den som vilket annat testfall som helst. Att köra en TestSuite-instans är samma sak som att iterera över sviten och köra varje test individuellt.

Om tests anges måste det vara en iterabel av enskilda testfall eller andra testsviter som kommer att användas för att bygga upp sviten initialt. Ytterligare metoder tillhandahålls för att lägga till testfall och sviter till samlingen senare.

TestSuite-objekt beter sig ungefär som TestCase-objekt, förutom att de inte implementerar ett test. Istället används de för att samla ihop tester till grupper av tester som ska köras tillsammans. Det finns några ytterligare metoder för att lägga till tester i TestSuite-instanser:

addTest(test)¶: Lägg till ett TestCase eller TestSuite till sviten.

addTests(tests)¶

Lägg till alla tester från en iterabel med instanser av TestCase och TestSuite till denna testsvit.

Detta är likvärdigt med att iterera över tester och anropa addTest() för varje element.

TestSuite delar följande metoder med TestCase:

run(result)¶: Kör de tester som är associerade med denna svit och samla in resultatet i testresultatobjektet som skickas som result. Observera att till skillnad från TestCase.run() kräver TestSuite.run() att resultatobjektet skickas in.

debug()¶: Kör de tester som är kopplade till denna svit utan att samla in resultatet. Detta gör att undantag som uppstår i testet kan vidarebefordras till den som anropar och kan användas för att köra tester under en debugger.

countTestCases()¶: Returnerar antalet tester som representeras av detta testobjekt, inklusive alla enskilda tester och undergrupper.

__iter__()¶: Tester som grupperas av en TestSuite nås alltid genom iteration. Underklasser kan lata tillhandahålla tester genom att åsidosätta __iter__(). Observera att den här metoden kan anropas flera gånger på en enda svit (t.ex. när man räknar tester eller jämför för likhet) så de tester som returneras av upprepade iterationer före TestSuite.run() måste vara desamma för varje anropsiteration. Efter TestSuite.run() bör anropare inte förlita sig på de tester som returneras av denna metod om inte anroparen använder en subklass som åsidosätter TestSuite._removeTestAtIndex() för att bevara testreferenser.

Ändrad i version 3.2: I tidigare versioner hade TestSuite tillgång till tester direkt snarare än genom iteration, så att åsidosätta __iter__() var inte tillräckligt för att tillhandahålla tester.

Ändrad i version 3.4: I tidigare versioner behöll TestSuite referenser till varje TestCase efter TestSuite.run(). Underklasser kan återställa detta beteende genom att åsidosätta TestSuite._removeTestAtIndex().

I den typiska användningen av ett TestSuite-objekt anropas run()-metoden av en TestRunner snarare än av slutanvändarens testprogram.

Ladda och köra tester¶

class unittest.TestLoader¶

Klassen TestLoader används för att skapa testsviter från klasser och moduler. Normalt finns det inget behov av att skapa en instans av den här klassen; modulen unittest tillhandahåller en instans som kan delas som unittest.defaultTestLoader. Om du använder en underklass eller instans kan du dock anpassa vissa konfigurerbara egenskaper.

TestLoader-objekt har följande attribut:

errors¶: En lista över de icke-fatala fel som uppstår vid laddning av tester. Återställs inte av laddaren vid någon tidpunkt. Fatala fel signaleras genom att den relevanta metoden ger upphov till ett undantag för den som anropar. Icke-fatala fel indikeras också av ett syntetiskt test som kommer att ge upphov till det ursprungliga felet när det körs.

Tillagd i version 3.5.

TestLoader-objekt har följande metoder:

loadTestsFromTestCase(testCaseClass)¶

Returnerar en svit av alla testfall som ingår i den TestCase-deriverade testCaseClass.

En testfallsinstans skapas för varje metod som namnges av getTestCaseNames(). Som standard är detta de metodnamn som börjar med test. Om getTestCaseNames() inte returnerar några metoder, men metoden runTest() är implementerad, skapas ett enda testfall för den metoden istället.

loadTestsFromModule(module, *, pattern=None)¶

Returnerar en svit av alla testfall som ingår i den givna modulen. Den här metoden söker i module efter klasser som härrör från TestCase och skapar en instans av klassen för varje testmetod som definieras för klassen.

Anteckning

Även om det kan vara praktiskt att använda en hierarki av TestCase-avledda klasser för att dela fixturer och hjälpfunktioner, är det inte så bra att definiera testmetoder på basklasser som inte är avsedda att instansieras direkt med den här metoden. Det kan dock vara användbart när fixturerna är olika och definieras i underklasser.

Om en modul tillhandahåller en load_tests-funktion kommer den att anropas för att ladda testerna. Detta gör det möjligt för moduler att anpassa testladdningen. Detta är load_tests-protokollet. Argumentet pattern skickas som det tredje argumentet till load_tests.

Ändrad i version 3.2: Stöd för load_tests har lagts till.

Ändrad i version 3.5: Stöd för ett argument pattern som endast innehåller nyckelord har lagts till.

Ändrad i version 3.12: Den odokumenterade och inofficiella parametern use_load_tests har tagits bort.

loadTestsFromName(name, module=None)¶

Returnerar en svit med alla testfall som anges med en strängspecifikator.

Specificeraren name är ett ”prickat namn” som kan leda till antingen en modul, en testfallsklass, en testmetod i en testfallsklass, en instans av TestSuite eller ett anropsbart objekt som returnerar en instans av TestCase eller TestSuite. Dessa kontroller tillämpas i den ordning som anges här, dvs. en metod i en möjlig testfallsklass kommer att uppfattas som ”en testmetod i en testfallsklass”, snarare än ”ett anropbart objekt”.

Om du till exempel har en modul SampleTests som innehåller en TestCase-avledd klass SampleTestCase med tre testmetoder (test_one(), test_two() och test_three()), skulle specifikatorn 'SampleTests.SampleTestCase' göra att den här metoden returnerar en svit som kör alla tre testmetoderna. Om specifikatorn 'SampleTests.SampleTestCase.test_two' används kommer metoden att returnera en testsvit som endast kör testmetoden test_two(). Specificeraren kan hänvisa till moduler och paket som inte har importerats; de kommer att importeras som en bieffekt.

Metoden löser valfritt upp namn i förhållande till den angivna modulen.

Ändrad i version 3.5: Om ett ImportError eller AttributeError inträffar när name genomkorsas kommer ett syntetiskt test som ger upphov till felet att returneras. Dessa fel ingår i de fel som ackumuleras av self.errors.

loadTestsFromNames(names, module=None)¶: Liknar loadTestsFromName(), men tar en sekvens av namn i stället för ett enda namn. Returvärdet är en testsvit som stöder alla tester som definierats för varje namn.

getTestCaseNames(testCaseClass)¶: Returnerar en sorterad sekvens av metodnamn som finns inom testCaseClass; detta bör vara en subklass av TestCase.

discover(start_dir, pattern='test*.py', top_level_dir=None)¶

Hitta alla testmoduler genom att söka i underkataloger från den angivna startkatalogen och returnera ett TestSuite-objekt som innehåller dem. Endast testfiler som matchar mönster kommer att laddas. (Med hjälp av mönstermatchning i shell-stil.) Endast modulnamn som är importerbara (dvs. giltiga Python-identifierare) laddas.

Alla testmoduler måste kunna importeras från den översta nivån i projektet. Om startkatalogen inte är den översta katalogen måste top_level_dir anges separat.

Om importen av en modul misslyckas, t.ex. på grund av ett syntaxfel, registreras detta som ett enda fel och upptäckten fortsätter. Om importen misslyckas på grund av att SkipTest aktiveras, registreras det som en skip istället för ett fel.

Om ett paket (en katalog som innehåller en fil med namnet __init__.py) hittas, kommer paketet att kontrolleras för en load_tests-funktion. Om en sådan finns kommer den att kallas package.load_tests(loader, tests, pattern). Testdiscovery ser till att ett paket bara kontrolleras för tester en gång under en anrop, även om load_tests-funktionen själv anropar loader.discover.

Om load_tests existerar så rekurserar discovery inte in i paketet, load_tests ansvarar för att ladda alla tester i paketet.

Mönstret lagras avsiktligt inte som ett attribut för laddaren, så att paketen kan fortsätta att upptäcka sig själva.

top_level_dir lagras internt och används som standard för alla nästlade anrop till discover(). Det vill säga, om ett pakets load_tests anropar loader.discover(), behöver det inte skicka detta argument.

start_dir kan vara både ett punktat modulnamn och en katalog.

Tillagd i version 3.2.

Ändrad i version 3.4: Moduler som ger upphov till SkipTest vid import registreras som överhoppningar, inte fel.

start_dir kan vara en namespace packages.

Sökvägarna sorteras innan de importeras så att exekveringsordningen blir densamma även om det underliggande filsystemets ordning inte är beroende av filnamnet.

Ändrad i version 3.5: Hittade paket kontrolleras nu för load_tests oavsett om deras sökväg matchar pattern, eftersom det är omöjligt för ett paketnamn att matcha standardmönstret.

Ändrad i version 3.11: start_dir kan inte vara en namespace packages. Det har varit trasigt sedan Python 3.7, och Python 3.11 tar officiellt bort det.

Ändrad i version 3.13: top_level_dir lagras endast under den tid som discover-anropet pågår.

Ändrad i version 3.14: start_dir kan återigen vara en namespace package.

Följande attribut för en TestLoader kan konfigureras antingen genom subklassning eller genom tilldelning på en instans:

testMethodPrefix¶

Sträng som anger prefixet för metodnamn som ska tolkas som testmetoder. Standardvärdet är 'test'.

Detta påverkar getTestCaseNames() och alla loadTestsFrom*-metoder.

sortTestMethodsUsing¶: Funktion som ska användas för att jämföra metodnamn när de sorteras i getTestCaseNames() och alla loadTestsFrom*-metoder.

suiteClass¶

Anropsbart objekt som konstruerar en testsvit från en lista med tester. Inga metoder på det resulterande objektet behövs. Standardvärdet är klassen TestSuite.

Detta påverkar alla loadTestsFrom*-metoder.

testNamePatterns¶

Lista över testnamnsmönster med jokertecken i Unix-shell-stil som testmetoder måste matcha för att inkluderas i testsviter (se alternativet -k).

Om detta attribut inte är None (standard) måste alla testmetoder som ska ingå i testsviter matcha ett av mönstren i listan. Observera att matchningar alltid utförs med fnmatch.fnmatchcase(), så till skillnad från mönster som skickas till alternativet -k måste enkla delsträngsmönster konverteras med hjälp av jokertecken *.

Detta påverkar alla loadTestsFrom*-metoder.

Tillagd i version 3.7.

class unittest.TestResult¶

Denna klass används för att sammanställa information om vilka tester som har lyckats och vilka som har misslyckats.

Ett TestResult-objekt lagrar resultaten av en uppsättning tester. Klasserna TestCase och TestSuite säkerställer att resultaten registreras på rätt sätt; testförfattare behöver inte oroa sig för att registrera resultatet av testerna.

Testramverk som bygger på unittest kan vilja ha tillgång till TestResult-objektet som genereras genom att köra en uppsättning tester för rapporteringsändamål; en TestResult-instans returneras av TestRunner.run()-metoden för detta ändamål.

TestResult-instanser har följande attribut som är av intresse när man granskar resultatet av en uppsättning tester:

errors¶: En lista som innehåller 2-tupler av TestCase-instanser och strängar som innehåller formaterade spårningar. Varje tupel representerar ett test som gav upphov till ett oväntat undantag.

failures¶: En lista som innehåller 2-tupler av TestCase-instanser och strängar som innehåller formaterade spårningar. Varje tupel representerar ett test där ett fel uttryckligen signalerades med hjälp av assert*-metoderna.

skipped¶: En lista som innehåller 2-tupel av TestCase-instanser och strängar som anger orsaken till att testet hoppar över.

Tillagd i version 3.1.

expectedFailures¶: En lista som innehåller 2-tupler av TestCase-instanser och strängar som innehåller formaterade spårningar. Varje tupel representerar ett förväntat misslyckande eller fel i testfallet.

unexpectedSuccesses¶: En lista som innehåller TestCase-instanser som var markerade som förväntade misslyckanden, men som lyckades.

collectedDurations¶: En lista som innehåller 2-tuples av testfallsnamn och floats som representerar den förflutna tiden för varje test som kördes.

Tillagd i version 3.12.

shouldStop¶: Sätts till True när testkörningen ska stoppas med stop().

testsRun¶: Det totala antalet tester som körts hittills.

buffer¶: Om inställningen är true kommer sys.stdout och sys.stderr att buffras mellan anropen av startTest() och stopTest(). Insamlad utdata kommer endast att ekas till de riktiga sys.stdout och sys.stderr om testet misslyckas eller felar. Alla utdata bifogas också till felmeddelandet.

Tillagd i version 3.2.

failfast¶: Om inställningen är true kommer stop() att anropas vid det första misslyckandet eller felet, vilket stoppar testkörningen.

Tillagd i version 3.2.

tb_locals¶: Om värdet är true kommer lokala variabler att visas i spårningar.

Tillagd i version 3.5.

wasSuccessful()¶: Returnerar True om alla tester som körts hittills har godkänts, annars returneras False.

Ändrad i version 3.4: Returnerar False om det fanns några unexpectedSuccesses från tester markerade med expectedFailure() dekoratorn.

stop()¶

Denna metod kan anropas för att signalera att den uppsättning tester som körs bör avbrytas genom att sätta attributet shouldStop till True. TestRunner-objekt bör respektera denna flagga och återvända utan att köra några ytterligare tester.

Den här funktionen används t.ex. av klassen TextTestRunner för att stoppa testramverket när användaren signalerar ett avbrott från tangentbordet. Interaktiva verktyg som tillhandahåller TestRunner-implementationer kan använda detta på liknande sätt.

Följande metoder i klassen TestResult används för att underhålla de interna datastrukturerna och kan utökas i underklasser för att stödja ytterligare rapporteringskrav. Detta är särskilt användbart för att bygga verktyg som stöder interaktiv rapportering medan tester körs.

startTest(test)¶: Anropas när testfallet test ska köras.

stopTest(test)¶: Anropas efter att testfallet test har utförts, oavsett resultat.

startTestRun()¶: Anropas en gång innan några tester utförs.

Tillagd i version 3.1.

stopTestRun()¶: Anropas en gång efter att alla tester har utförts.

Tillagd i version 3.1.

addError(test, err)¶

Anropas när testfallet test ger upphov till ett oväntat undantag. err är en tupel av den form som returneras av sys.exc_info(): (type, value, traceback).

Standardimplementeringen lägger till en tupel (test, formatted_err) till instansens attribut errors, där formatted_err är en formaterad återgång som härrör från err.

addFailure(test, err)¶

Anropas när testfallet test signalerar ett misslyckande. err är en tupel av den form som returneras av sys.exc_info(): (type, value, traceback).

Standardimplementeringen lägger till en tupel (test, formatted_err) till instansens attribut failures, där formatted_err är en formaterad återgång som härrör från err.

addSuccess(test)¶

Anropas när testfallet test lyckas.

Standardimplementeringen gör ingenting.

addSkip(test, reason)¶

Anropas när testfallet test hoppar över. reason är den anledning som testet angav för att hoppa över.

Standardimplementeringen lägger till en tupel (test, reason) till instansens attribut skipped.

addExpectedFailure(test, err)¶

Anropas när testfallet test misslyckas eller felar, men var markerat med expectedFailure()-dekoratorn.

Standardimplementeringen lägger till en tupel (test, formatted_err) till instansens attribut expectedFailures, där formatted_err är en formaterad återgång som härrör från err.

addUnexpectedSuccess(test)¶

Anropas när testfallet test markerades med dekoratorn expectedFailure(), men lyckades.

Standardimplementeringen lägger till testet till instansens attribut unexpectedSuccesses.

addSubTest(test, subtest, outcome)¶

Anropas när ett deltest är avslutat. test är det testfall som motsvarar testmetoden. subtest är en anpassad TestCase-instans som beskriver subtestet.

Om outcome är None, lyckades deltestet. Annars misslyckades det med ett undantag där outcome är en tupel av den form som returneras av sys.exc_info(): (type, value, traceback).

Standardimplementeringen gör ingenting när resultatet är en framgång, och registrerar misslyckade deltest som normala misslyckanden.

Tillagd i version 3.4.

addDuration(test, elapsed)¶: Anropas när testfallet är avslutat. elapsed är tiden i sekunder och inkluderar exekvering av rensningsfunktioner.

Tillagd i version 3.12.

class unittest.TextTestResult(stream, descriptions, verbosity, *, durations=None)¶: En konkret implementation av TestResult som används av TextTestRunner. Underklasser bör acceptera **kwargs för att säkerställa kompatibilitet när gränssnittet ändras.

Tillagd i version 3.2.

Ändrad i version 3.12: Nyckelordsparametern durations har lagts till.

unittest.defaultTestLoader¶: Instans av klassen TestLoader som är avsedd att delas. Om ingen anpassning av TestLoader behövs, kan denna instans användas istället för att upprepade gånger skapa nya instanser.

class unittest.TextTestRunner(stream=None, descriptions=True, verbosity=1, failfast=False, buffer=False, resultclass=None, warnings=None, *, tb_locals=False, durations=None)¶

En grundläggande implementering av en testlöpare som matar ut resultat till en ström. Om stream är None används standardvärdet sys.stderr som utdataflöde. Den här klassen har några konfigurerbara parametrar, men är i grunden mycket enkel. Grafiska applikationer som kör testsviter bör tillhandahålla alternativa implementationer. Sådana implementationer bör acceptera **kwargs eftersom gränssnittet för att konstruera löpare ändras när funktioner läggs till i unittest.

Som standard visar den här löparen DeprecationWarning, PendingDeprecationWarning, ResourceWarning och ImportWarning även om de är ignorerade som standard. Detta beteende kan åsidosättas genom att använda Pythons -Wd eller -Wa (se Warning control) och lämna warnings till None.

Ändrad i version 3.2: Parametern warnings har lagts till.

Ändrad i version 3.2: Standardströmmen är inställd på sys.stderr vid instantiering istället för vid import.

Ändrad i version 3.5: Parametern tb_locals har lagts till.

Ändrad i version 3.12: Parametern durations har lagts till.

_makeResult()¶

Denna metod returnerar den instans av TestResult som används av run(). Den är inte avsedd att anropas direkt, men kan åsidosättas i subklasser för att tillhandahålla ett eget TestResult.

_makeResult() instansierar klassen eller anropsbarheten som skickas i TextTestRunner konstruktören som resultclass argument. Standardvärdet är TextTestResult om ingen resultclass anges. Resultatklassen instansieras med följande argument:

stream, descriptions, verbosity

run(test)¶: Denna metod är det huvudsakliga publika gränssnittet till TextTestRunner. Denna metod tar en TestSuite eller TestCase instans. Ett TestResult skapas genom att anropa _makeResult() och testet(en) körs och resultaten skrivs ut till stdout.

unittest.main(module='__main__', defaultTest=None, argv=None, testRunner=None, testLoader=unittest.defaultTestLoader, exit=True, verbosity=1, failfast=None, catchbreak=None, buffer=None, warnings=None)¶

Ett kommandoradsprogram som laddar en uppsättning tester från modul och kör dem; detta är främst till för att göra testmoduler praktiskt körbara. Den enklaste användningen av denna funktion är att inkludera följande rad i slutet av ett testskript:

if __name__ == '__main__':
    unittest.main()

Du kan köra tester med mer detaljerad information genom att ange argumentet verbosity:

if __name__ == '__main__':
    unittest.main(ordrikhet=2)

Argumentet defaultTest är antingen namnet på ett enskilt test eller en iterabel med testnamn som ska köras om inga testnamn anges via argv. Om det inte specificeras eller None och inga testnamn anges via argv, körs alla tester som finns i module.

Argumentet argv kan vara en lista med alternativ som skickas till programmet, där det första elementet är programnamnet. Om inget anges eller None, används värdena i sys.argv.

Argumentet testRunner kan antingen vara en testlöparklass eller en redan skapad instans av den. Som standard anropar main sys.exit() med en utgångskod som anger om testerna som körts lyckades (0) eller misslyckades (1). En exit-kod på 5 anger att inga tester kördes eller att de hoppades över.

Argumentet testLoader måste vara en instans av TestLoader, och standardvärdet är defaultTestLoader.

main kan användas från den interaktiva tolken genom att skicka in argumentet exit=False. Detta visar resultatet på standardutmatningen utan att anropa sys.exit():

>>> from unittest import main
>>> main(module='test_module', exit=False)

Parametrarna failfast, catchbreak och buffer har samma effekt som kommandoradsalternativen med samma namn.

Argumentet warnings anger det varningsfilter som ska användas när testerna körs. Om det inte anges kommer det att förbli None om ett -W-alternativ skickas till python (se Warning control), annars kommer det att sättas till 'default'.

Anrop av main returnerar ett objekt med attributet result som innehåller resultatet av de tester som körts som en unittest.TestResult.

Ändrad i version 3.1: Parametern exit har lagts till.

Ändrad i version 3.2: Parametrarna verbosity, failfast, catchbreak, buffer och warnings har lagts till.

Ändrad i version 3.4: Parametern defaultTest har ändrats så att den även accepterar en iterabel med testnamn.

load_tests Protokoll¶

Tillagd i version 3.2.

Moduler eller paket kan anpassa hur tester laddas från dem under normala testkörningar eller testupptäckt genom att implementera en funktion som heter load_tests.

Om en testmodul definierar load_tests kommer den att anropas av TestLoader.loadTestsFromModule() med följande argument:

load_tests(loader, standard_tests, pattern)

där mönster skickas rakt igenom från loadTestsFromModule. Standardvärdet är None.

Den bör returnera en TestSuite.

loader är den instans av TestLoader som gör inläsningen. standard_tests är de tester som laddas som standard från modulen. Det är vanligt att testmoduler bara vill lägga till eller ta bort tester från standarduppsättningen av tester. Det tredje argumentet används när paket laddas som en del av testupptäckten.

En typisk load_tests-funktion som laddar tester från en specifik uppsättning TestCase-klasser kan se ut på följande sätt:

test_cases = (TestCase1, TestCase2, TestCase3)

def load_tests(loader, tests, pattern):
    suite = TestSuite()
    for test_class in test_cases:
        tests = loader.loadTestsFromTestCase(test_class)
        suite.addTests(tests)
    return suite

Om discovery startas i en katalog som innehåller ett paket, antingen från kommandoraden eller genom att anropa TestLoader.discover(), kommer paketet __init__.py att kontrolleras med avseende på load_tests. Om den funktionen inte finns kommer discovery att rekursera i paketet som om det vore en katalog. Annars kommer upptäckten av paketets tester att överlåtas till load_tests som anropas med följande argument:

load_tests(loader, standard_tests, pattern)

Detta bör returnera en TestSuite som representerar alla tester från paketet. (standard_tests kommer endast att innehålla tester som hämtats från __init__.py.)

Eftersom mönstret skickas in i load_tests är paketet fritt att fortsätta (och eventuellt modifiera) testupptäckten. En ”gör ingenting” load_tests funktion för ett testpaket skulle se ut som:

def load_tests(loader, standard_tests, pattern):
    # top level directory cached on loader instance
    this_dir = os.path.dirname(__file__)
    package_tests = loader.discover(start_dir=this_dir, pattern=pattern)
    standard_tests.addTests(package_tests)
    return standard_tests

Ändrad i version 3.5: Discovery kontrollerar inte längre om paketnamn matchar pattern eftersom det är omöjligt att paketnamn matchar standardmönstret.

Klass- och modulfixturer¶

Fixturer på klass- och modulnivå är implementerade i TestSuite. När testsviten stöter på ett test från en ny klass anropas tearDownClass() från den tidigare klassen (om det finns en sådan), följt av setUpClass() från den nya klassen.

På samma sätt om ett test är från en annan modul än det föregående testet så körs tearDownModule från den föregående modulen, följt av setUpModule från den nya modulen.

Efter att alla tester har körts körs de slutliga tearDownClass och tearDownModule.

Observera att delade fixturer inte fungerar bra med [potentiella] funktioner som testparallellisering och att de bryter testisolering. De bör användas med försiktighet.

Standardordningen för tester som skapas av unittests testladdare är att gruppera alla tester från samma moduler och klasser tillsammans. Detta kommer att leda till att setUpClass / setUpModule (etc) anropas exakt en gång per klass och modul. Om du slumpar ordningen, så att tester från olika moduler och klasser ligger intill varandra, kan dessa delade fixture-funktioner anropas flera gånger under en enda testkörning.

Delade fixturer är inte avsedda att fungera med sviter med icke-standardiserad ordningsföljd. En BaseTestSuite finns fortfarande för ramverk som inte vill stödja delade fixturer.

Om det uppstår några undantag under någon av de delade fixturfunktionerna rapporteras testet som ett fel. Eftersom det inte finns någon motsvarande testinstans skapas ett _ErrorHolder-objekt (som har samma gränssnitt som ett TestCase) för att representera felet. Om du bara använder standardtestköraren unittest spelar den här detaljen ingen roll, men om du är ramverksförfattare kan det vara relevant.

setUpClass och tearDownClass¶

Dessa måste implementeras som klassmetoder:

import unittest

class Test(unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        cls._connection = createExpensiveConnectionObject()

    @classmethod
    def tearDownClass(cls):
        cls._connection.destroy()

Om du vill att setUpClass och tearDownClass på basklasser skall anropas måste du själv anropa dem. Implementationerna i TestCase är tomma.

Om ett undantag uppstår under en setUpClass så körs inte testerna i klassen och tearDownClass körs inte. Klasser som hoppats över kommer inte att få setUpClass eller tearDownClass körda. Om undantaget är ett SkipTest-undantag kommer klassen att rapporteras som att den har hoppats över istället för som ett fel.

setUpModule och tearDownModule¶

Dessa bör implementeras som funktioner:

def setUpModule():
    createConnection()

def tearDownModule():
    closeConnection()

Om ett undantag uppstår i en setUpModule kommer inget av testerna i modulen att köras och tearDownModule kommer inte att köras. Om undantaget är ett SkipTest-undantag kommer modulen att rapporteras som att den har hoppats över istället för som ett fel.

Om du vill lägga till uppstädningskod som måste köras även vid undantag använder du addModuleCleanup:

unittest.addModuleCleanup(function, /, *args, **kwargs)¶

Lägg till en funktion som ska anropas efter tearDownModule() för att städa upp resurser som använts under testklassen. Funktioner kommer att anropas i omvänd ordning mot den ordning de läggs till (LIFO). De anropas med alla argument och nyckelordsargument som skickas in i addModuleCleanup() när de läggs till.

Om setUpModule() misslyckas, vilket innebär att tearDownModule() inte anropas, så kommer eventuella cleanup-funktioner som lagts till ändå att anropas.

Tillagd i version 3.8.

unittest.enterModuleContext(cm)¶: Ange den medföljande context manager. Om det lyckas, lägg även till dess __exit__()-metod som en uppstädningsfunktion med addModuleCleanup() och returnera resultatet av __enter__()-metoden.

Tillagd i version 3.11.

unittest.doModuleCleanups()¶

Denna funktion anropas ovillkorligen efter tearDownModule(), eller efter setUpModule() om setUpModule() ger upphov till ett undantag.

Den är ansvarig för att anropa alla upprensningsfunktioner som lagts till av addModuleCleanup(). Om du vill att rensningsfunktionerna ska anropas före tearDownModule() kan du anropa doModuleCleanups() själv.

doModuleCleanups() plockar bort metoder från stacken med rensningsfunktioner en i taget, så att den kan anropas när som helst.

Tillagd i version 3.8.

Signalhantering¶

Tillagd i version 3.2.

Kommandoradsalternativet -c/--catch till unittest, tillsammans med parametern catchbreak till unittest.main(), ger en mer vänlig hantering av control-C under en testkörning. Med catch break-beteendet aktiverat kommer control-C att låta det pågående testet slutföras, och testkörningen kommer sedan att avslutas och rapportera alla resultat så här långt. En andra kontroll-c kommer att ge upphov till en KeyboardInterrupt på vanligt sätt.

Signalhanteraren för kontroll-c försöker vara kompatibel med kod eller tester som installerar sin egen signal.SIGINT-hanterare. Om unittest-hanteraren anropas men inte är den installerade signal.SIGINT-hanteraren, d.v.s. den har ersatts av systemet som testas och delegerats till, anropas standardhanteraren. Detta är normalt det förväntade beteendet hos kod som ersätter en installerad hanterare och delegerar till den. För enskilda tester som behöver unittest kontroll-c hantering inaktiverad kan removeHandler() dekoratorn användas.

Det finns ett fåtal funktioner för ramverksförfattare som gör det möjligt att hantera kontroll-c-funktioner i testramverk.

unittest.installHandler()¶: Installera control-c hanteraren. När en signal.SIGINT tas emot (vanligtvis som svar på att användaren trycker på control-c) kommer alla registrerade resultat att anropas stop().

unittest.registerResult(result)¶

Registrera ett TestResult-objekt för kontrollhantering. Genom att registrera ett resultat lagras en svag referens till det, så det hindrar inte att resultatet samlas in i en soptunna.

Registrering av ett TestResult-objekt har inga bieffekter om kontroll-c-hantering inte är aktiverad, så testramverk kan ovillkorligen registrera alla resultat de skapar oberoende av om hantering är aktiverad eller inte.

unittest.removeResult(result)¶: Ta bort ett registrerat resultat. När ett resultat har tagits bort kommer stop() inte längre att anropas på det resultatobjektet som svar på ett kontroll-c.

unittest.removeHandler(function=None)¶

När den anropas utan argument tar denna funktion bort kontroll-c-hanteraren om den har installerats. Denna funktion kan också användas som en testdekorator för att tillfälligt ta bort hanteraren medan testet körs:

@unittest.removeHandler
def test_signal_handling(self):
    ...

`unittest` — Ramverk för enhetstestning¶

Grundläggande exempel¶

Kommandoradsgränssnitt¶

Alternativ för kommandoraden¶

Testupptäckt¶

Organisering av testkod¶

Återanvändning av gammal testkod¶

Skippa tester och förväntade misslyckanden¶

Särskiljande av testiterationer med hjälp av deltest¶

Klasser och funktioner¶

Testfall¶

Gruppering av tester¶

Ladda och köra tester¶

load_tests Protokoll¶

Klass- och modulfixturer¶

setUpClass och tearDownClass¶

setUpModule och tearDownModule¶

Signalhantering¶

Innehåll

Föregående ämne

Nästa ämne

Denna sidan

unittest — Ramverk för enhetstestning¶

Grundläggande exempel¶

Kommandoradsgränssnitt¶

Alternativ för kommandoraden¶

Testupptäckt¶

Organisering av testkod¶

Återanvändning av gammal testkod¶

Skippa tester och förväntade misslyckanden¶

Särskiljande av testiterationer med hjälp av deltest¶

Klasser och funktioner¶

Testfall¶

Gruppering av tester¶

Ladda och köra tester¶

load_tests Protokoll¶

Klass- och modulfixturer¶

setUpClass och tearDownClass¶

setUpModule och tearDownModule¶

Signalhantering¶

`unittest` — Ramverk för enhetstestning¶