`unittest` — Unit testing framework¶

Quellcode: Lib/unittest/__init__.py

(Wenn Sie mit den grundlegenden Konzepten des Testens bereits vertraut sind, möchten Sie vielleicht zu der Liste der Assertionsmethoden springen.)

Das unittest Unit-Testing-Framework wurde ursprünglich von JUnit inspiriert und hat einen ähnlichen Charakter wie die wichtigsten Unit-Testing-Frameworks in anderen Sprachen. Es unterstützt Testautomatisierung, das Teilen von Setup- und Shutdown-Code für Tests, die Aggregation von Tests in Sammlungen und die Unabhängigkeit der Tests vom Reporting-Framework.

Um dies zu erreichen, unterstützt unittest einige wichtige Konzepte auf objektorientierte Weise:

Test-Fixture: Ein Test-Fixture repräsentiert die Vorbereitung, die für die Durchführung eines oder mehrerer Tests erforderlich ist, sowie alle damit verbundenen Aufräumarbeiten. Dies kann beispielsweise die Erstellung temporärer oder Proxy-Datenbanken, Verzeichnisse oder den Start eines Serverprozesses umfassen.
Testfall: Ein Testfall ist die einzelne Einheit des Testens. Er prüft auf eine spezifische Antwort auf einen bestimmten Satz von Eingaben. unittest stellt eine Basisklasse, TestCase, bereit, die zur Erstellung neuer Testfälle verwendet werden kann.
Test-Suite: Eine Test-Suite ist eine Sammlung von Testfällen, Test-Suiten oder beidem. Sie wird verwendet, um Tests zu aggregieren, die zusammen ausgeführt werden sollen.
Test-Runner: Ein Test-Runner ist eine Komponente, die die Ausführung von Tests orchestriert und dem Benutzer das Ergebnis liefert. Der Runner kann eine grafische Oberfläche, eine textbasierte Oberfläche verwenden oder einen speziellen Wert zurückgeben, um die Ergebnisse der Testausführung anzuzeigen.

Siehe auch

Modul doctest: Ein weiteres testunterstützendes Modul mit einem ganz anderen Charakter.
Simple Smalltalk Testing: With Patterns: Kent Becks ursprünglicher Artikel über Test-Frameworks, der sich auf das Muster stützt, das von unittest geteilt wird.
pytest: Drittanbieter-Unittest-Framework mit einer leichteren Syntax für das Schreiben von Tests. Zum Beispiel: assert func(10) == 42.
Die Python Testing Tools Taxonomy: Eine umfangreiche Liste von Python-Testwerkzeugen, einschließlich funktionaler Test-Frameworks und Mock-Objekt-Bibliotheken.
Testing in Python Mailing List: Eine Interessengruppe für die Diskussion von Tests und Testwerkzeugen in Python.

Das Skript Tools/unittestgui/unittestgui.py in der Python-Quellcodeverteilung ist ein GUI-Tool für die Testfindung und -ausführung. Dies ist hauptsächlich für den einfachen Einstieg für Neulinge im Unit-Testing gedacht. Für Produktionsumgebungen wird empfohlen, Tests über ein Continuous-Integration-System wie Buildbot, Jenkins, GitHub Actions oder AppVeyor laufen zu lassen.

Einfaches Beispiel¶

Das Modul unittest bietet einen reichhaltigen Satz an Werkzeugen zum Erstellen und Ausführen von Tests. Dieser Abschnitt zeigt, dass eine kleine Teilmenge der Werkzeuge ausreicht, um die Bedürfnisse der meisten Benutzer zu erfüllen.

Hier ist ein kurzes Skript, um drei String-Methoden zu testen

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()

Ein Testfall wird durch Unterklasse von unittest.TestCase erstellt. Die drei einzelnen Tests werden mit Methoden definiert, deren Namen mit den Buchstaben test beginnen. Diese Namenskonvention informiert den Test-Runner darüber, welche Methoden Tests darstellen.

Der Kern jedes Tests ist ein Aufruf von assertEqual(), um ein erwartetes Ergebnis zu überprüfen; assertTrue() oder assertFalse(), um eine Bedingung zu überprüfen; oder assertRaises(), um zu überprüfen, ob eine bestimmte Ausnahme ausgelöst wird. Diese Methoden werden anstelle der assert-Anweisung verwendet, damit der Test-Runner alle Testergebnisse sammeln und einen Bericht erstellen kann.

Die Methoden setUp() und tearDown() ermöglichen es Ihnen, Anweisungen zu definieren, die vor und nach jeder Testmethode ausgeführt werden. Sie werden im Abschnitt Organisation des Testcodes detaillierter behandelt.

Der letzte Block zeigt eine einfache Möglichkeit, die Tests auszuführen. unittest.main() bietet eine Kommandozeilenschnittstelle zum Testskript. Wenn es von der Kommandozeile aus ausgeführt wird, erzeugt das obige Skript eine Ausgabe, die wie folgt aussieht:

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

OK

Wenn Sie die Option -v an Ihr Testskript übergeben, wird unittest.main() angewiesen, eine höhere Detailstufe zu aktivieren und die folgende Ausgabe zu erzeugen:

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

Die obigen Beispiele zeigen die am häufigsten verwendeten Funktionen von unittest, die für viele tägliche Testanforderungen ausreichen. Der Rest der Dokumentation untersucht den vollständigen Funktionsumfang von Grund auf.

Geändert in Version 3.11: Das Verhalten bei der Rückgabe eines Wertes aus einer Testmethode (außer dem Standardwert None) ist jetzt veraltet.

Befehlszeilenschnittstelle¶

Das `unittest`-Modul kann von der Kommandozeile aus verwendet werden, um Tests aus Modulen, Klassen oder sogar einzelnen Testmethoden auszuführen.

python -m unittest test_module1 test_module2
python -m unittest test_module.TestClass
python -m unittest test_module.TestClass.test_method

Sie können eine Liste mit beliebigen Kombinationen von Modulnamen sowie vollqualifizierten Klassen- oder Methodennamen übergeben.

Testmodule können auch nach Dateipfad angegeben werden.

python -m unittest tests/test_something.py

Dadurch können Sie die Shell-Dateinamenvervollständigung zur Angabe des Testmoduls verwenden. Die angegebene Datei muss immer noch als Modul importierbar sein. Der Pfad wird in einen Modulnamen umgewandelt, indem '.py' entfernt und Pfadtrennzeichen durch '.' ersetzt werden. Wenn Sie eine Testdatei ausführen möchten, die nicht als Modul importierbar ist, sollten Sie stattdessen die Datei direkt ausführen.

Sie können Tests mit mehr Details (höherer Detailgrad) ausführen, indem Sie das Flag -v übergeben.

python -m unittest -v test_module

Wenn Test Discovery ohne Argumente ausgeführt wird.

python -m unittest

Für eine Liste aller Kommandozeilenoptionen

python -m unittest -h

Geändert in Version 3.2: In früheren Versionen war es nur möglich, einzelne Testmethoden und keine Module oder Klassen auszuführen.

Hinzugefügt in Version 3.14: Die Ausgabe ist standardmäßig farbig und kann über Umgebungsvariablen gesteuert werden.

Kommandozeilenoptionen¶

unittest unterstützt diese Kommandozeilenoptionen

-b, --buffer¶: Die Standardausgabe und der Standardfehlerausgabe werden während des Testlaufs gepuffert. Die Ausgabe während eines erfolgreichen Tests wird verworfen. Die Ausgabe wird bei fehlgeschlagenen oder fehlerhaften Tests normal ausgegeben und den Fehlermeldungen hinzugefügt.

-c, --catch¶

Steuerung-C während des Testlaufs wartet, bis der aktuelle Test beendet ist, und meldet dann alle bisherigen Ergebnisse. Ein zweites Steuerung-C löst die normale KeyboardInterrupt-Ausnahme aus.

Siehe Signal Handling für die Funktionen, die diese Funktionalität bereitstellen.

-f, --failfast¶: Beenden Sie den Testlauf beim ersten Fehler oder Fehlschlag.

-k¶

Führen Sie nur Testmethoden und -klassen aus, die dem Muster oder Teilstring entsprechen. Diese Option kann mehrmals verwendet werden, in diesem Fall werden alle Testfälle einbezogen, die einem der angegebenen Muster entsprechen.

Muster, die ein Platzhaltersymbol (*) enthalten, werden anhand des Testnamens mit fnmatch.fnmatchcase() verglichen; andernfalls wird ein einfacher exakter Teilstring-Vergleich verwendet.

Muster werden mit dem vollqualifizierten Namen der Testmethode verglichen, wie er vom Testlader importiert wird.

Zum Beispiel passt -k foo zu foo_tests.SomeTest.test_something, bar_tests.SomeTest.test_foo, aber nicht zu bar_tests.FooTest.test_something.

--locals¶: Lokale Variablen in Tracebacks anzeigen.

--durations N¶: Die N langsamsten Testfälle anzeigen (N=0 für alle).

Hinzugefügt in Version 3.2: Die Kommandozeilenoptionen -b, -c und -f wurden hinzugefügt.

Hinzugefügt in Version 3.5: Die Kommandozeilenoption --locals.

Hinzugefügt in Version 3.7: Die Kommandozeilenoption -k.

Hinzugefügt in Version 3.12: Die Kommandozeilenoption --durations.

Die Kommandozeile kann auch für die Testfindung verwendet werden, um alle Tests in einem Projekt oder nur eine Teilmenge auszuführen.

Test-Discovery¶

Hinzugefügt in Version 3.2.

Unittest unterstützt einfache Testfindung. Um mit der Testfindung kompatibel zu sein, müssen alle Testdateien Module oder Pakete sein, die vom Top-Level-Verzeichnis des Projekts importierbar sind (was bedeutet, dass ihre Dateinamen gültige Identifikatoren sein müssen).

Die Testfindung ist in TestLoader.discover() implementiert, kann aber auch von der Kommandozeile aus verwendet werden. Die grundlegende Verwendung über die Kommandozeile ist:

cd project_directory
python -m unittest discover

Hinweis

Als Abkürzung ist python -m unittest gleichbedeutend mit python -m unittest discover. Wenn Sie Argumente an die Testfindung übergeben möchten, muss der Unterbefehl discover explizit verwendet werden.

Der Unterbefehl discover hat die folgenden Optionen:

-v, --verbose¶: Ausführliche Ausgabe

-s, --start-directory directory¶: Verzeichnis, ab dem die Suche beginnen soll (. ist Standard)

-p, --pattern pattern¶: Muster, nach dem Testdateien gesucht werden sollen (test*.py ist Standard)

-t, --top-level-directory directory¶: Top-Level-Verzeichnis des Projekts (Standard ist das Startverzeichnis)

Die Optionen -s, -p und -t können in dieser Reihenfolge als Positionsargumente übergeben werden. Die folgenden beiden Kommandozeilenaufrufe sind äquivalent:

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

Neben einem Pfad ist es auch möglich, einen Paketnamen anzugeben, z. B. myproject.subpackage.test, als Startverzeichnis. Der von Ihnen angegebene Paketname wird dann importiert und sein Speicherort im Dateisystem wird als Startverzeichnis verwendet.

Vorsicht

Test-Discovery lädt Tests durch Importieren. Sobald Test-Discovery alle Testdateien aus dem von Ihnen angegebenen Startverzeichnis gefunden hat, wandelt es die Pfade in Paketnamen zum Importieren um. Zum Beispiel wird foo/bar/baz.py als foo.bar.baz importiert.

Wenn Sie ein Paket global installiert haben und versuchen, Test-Discovery für eine andere Kopie des Pakets durchzuführen, kann der Import *von der falschen Stelle* erfolgen. Wenn dies geschieht, wird Test-Discovery Sie warnen und beenden.

Wenn Sie das Startverzeichnis als Paketnamen anstelle eines Verzeichnispfads angeben, geht Discover davon aus, dass der Ort, von dem es importiert, der von Ihnen beabsichtigte Ort ist, sodass Sie keine Warnung erhalten.

Testmodule und -pakete können das Laden und die Entdeckung von Tests über das load_tests-Protokoll anpassen.

Geändert in Version 3.4: Test-Discovery unterstützt Namensraum-Pakete.

Geändert in Version 3.11: Test-Discovery hat die Unterstützung für Namensraum-Pakete eingestellt. Sie war seit Python 3.7 fehlerhaft. Das Startverzeichnis und seine Unterverzeichnisse, die Tests enthalten, müssen reguläre Pakete sein, die eine Datei __init__.py enthalten.

Wenn das Startverzeichnis der Punkt-Notation des Pakets entspricht, können die übergeordneten Pakete Namensraum-Pakete sein.

Geändert in Version 3.14: Test-Discovery unterstützt wieder Namensraum-Pakete als Startverzeichnis. Um Verzeichnisse zu vermeiden, die nichts mit Python zu tun haben, werden Tests nicht in Unterverzeichnissen gesucht, die keine __init__.py-Datei enthalten.

Organisation des Testcodes¶

Die grundlegenden Bausteine des Unit-Testings sind Testfälle – einzelne Szenarien, die vorbereitet und auf Korrektheit geprüft werden müssen. In unittest werden Testfälle durch unittest.TestCase-Instanzen repräsentiert. Um Ihre eigenen Testfälle zu erstellen, müssen Sie Unterklassen von TestCase schreiben oder FunctionTestCase verwenden.

Der Testcode einer TestCase-Instanz sollte vollständig in sich geschlossen sein, so dass er entweder isoliert oder in beliebiger Kombination mit einer beliebigen Anzahl anderer Testfälle ausgeführt werden kann.

Die einfachste TestCase-Unterklasse implementiert einfach eine Testmethode (d. h. eine Methode, deren Name mit test beginnt), um spezifischen Testcode auszuführen.

import unittest

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

Beachten Sie, dass wir zum Testen von etwas eine der assert*-Methoden verwenden, die von der Basisklasse TestCase bereitgestellt werden. Wenn der Test fehlschlägt, wird eine Ausnahme mit einer erklärenden Meldung ausgelöst, und unittest identifiziert den Testfall als Fehler. Alle anderen Ausnahmen werden als Fehler behandelt.

Tests können zahlreich sein und ihre Vorbereitung kann repetitiv sein. Glücklicherweise können wir Vorbereitungscode auslagern, indem wir eine Methode namens setUp() implementieren, die das Test-Framework automatisch für jede von uns ausgeführte Testmethode aufruft.

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')

Hinweis

Die Reihenfolge, in der die verschiedenen Tests ausgeführt werden, wird durch Sortieren der Testmethodennamen in Bezug auf die eingebaute Sortierung für Strings bestimmt.

Wenn die Methode setUp() während der Ausführung des Tests eine Ausnahme auslöst, betrachtet das Framework den Test als fehlerhaft, und die Testmethode wird nicht ausgeführt.

Ebenso können wir eine Methode tearDown() bereitstellen, die nach der Ausführung der Testmethode aufräumt.

import unittest

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

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

Wenn setUp() erfolgreich war, wird tearDown() ausgeführt, unabhängig davon, ob die Testmethode erfolgreich war oder nicht.

Eine solche Arbeitsumgebung für den Testcode wird als Test-Fixture bezeichnet. Eine neue TestCase-Instanz wird als eindeutiges Test-Fixture erstellt, das zur Ausführung jeder einzelnen Testmethode verwendet wird. Daher werden setUp(), tearDown() und __init__() einmal pro Test aufgerufen.

Es wird empfohlen, TestCase-Implementierungen zu verwenden, um Tests nach den getesteten Funktionen zu gruppieren. unittest bietet einen Mechanismus dafür: die Test-Suite, repräsentiert durch die Klasse unittest’s TestSuite. In den meisten Fällen erledigt ein Aufruf von unittest.main() das Richtige und sammelt alle Testfälle des Moduls und führt sie aus.

Wenn Sie jedoch die Erstellung Ihrer Test-Suite anpassen möchten, können Sie dies selbst tun:

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())

Sie können die Definitionen von Testfällen und Test-Suiten in denselben Modulen wie der Code, den sie testen sollen (wie z. B. widget.py), platzieren, aber es gibt mehrere Vorteile, den Testcode in einem separaten Modul zu platzieren, wie z. B. test_widget.py:

Das Testmodul kann eigenständig von der Kommandozeile aus ausgeführt werden.
Der Testcode kann leichter vom ausgelieferten Code getrennt werden.
Es besteht weniger Versuchung, Testcode zu ändern, um ihn an den Code anzupassen, den er testet, ohne guten Grund.
Testcode sollte viel seltener geändert werden als der Code, den er testet.
Getesteter Code kann einfacher refaktoriert werden.
Tests für in C geschriebene Module müssen ohnehin in separaten Modulen sein, warum also nicht konsistent sein?
Wenn sich die Teststrategie ändert, müssen Sie den Quellcode nicht ändern.

Wiederverwendung von altem Testcode¶

Einige Benutzer werden feststellen, dass sie vorhandenen Testcode haben, den sie gerne aus unittest ausführen möchten, ohne jede alte Testfunktion in eine TestCase-Unterklasse zu konvertieren.

Aus diesem Grund bietet unittest eine Klasse FunctionTestCase. Diese Unterklasse von TestCase kann verwendet werden, um eine vorhandene Testfunktion zu umschließen. Setup- und Teardown-Funktionen können ebenfalls bereitgestellt werden.

Gegeben die folgende Testfunktion:

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

kann eine äquivalente Testfallinstanz wie folgt erstellt werden, mit optionalen Setup- und Teardown-Methoden:

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

Hinweis

Obwohl FunctionTestCase verwendet werden kann, um eine bestehende Testbasis schnell in ein unittest-basiertes System zu konvertieren, wird dieser Ansatz nicht empfohlen. Wenn Sie sich die Zeit nehmen, ordnungsgemäße TestCase-Unterklassen einzurichten, wird dies zukünftige Testrefactorings unendlich erleichtern.

In einigen Fällen wurden die bestehenden Tests möglicherweise mit dem Modul doctest geschrieben. Wenn dies der Fall ist, stellt doctest eine Klasse DocTestSuite bereit, die automatisch unittest.TestSuite-Instanzen aus den vorhandenen doctest-basierten Tests erstellen kann.

Tests überspringen und erwartete Fehler¶

Hinzugefügt in Version 3.1.

Unittest unterstützt das Überspringen einzelner Testmethoden und sogar ganzer Testklassen. Darüber hinaus unterstützt es das Markieren eines Tests als „erwarteter Fehler“, d. h. eines Tests, der fehlerhaft ist und fehlschlagen wird, aber in einem TestResult nicht als Fehler gezählt werden sollte.

Ein Testüberspringen ist einfach eine Frage der Verwendung des skip() Dekorators oder einer seiner bedingten Varianten, des Aufrufs von TestCase.skipTest() innerhalb einer setUp() oder Testmethode oder des direkten Auslösens von SkipTest.

Grundlegendes Überspringen sieht so aus

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

Dies ist die Ausgabe des Ausführens des obigen Beispiels im ausführlichen Modus

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)

Klassen können wie Methoden übersprungen werden

@unittest.skip("showing class skipping")
class MySkippedTestCase(unittest.TestCase):
    def test_not_run(self):
        pass

TestCase.setUp() kann den Test ebenfalls überspringen. Dies ist nützlich, wenn eine Ressource, die eingerichtet werden muss, nicht verfügbar ist.

Erwartete Fehler verwenden den expectedFailure() Dekorator.

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

Es ist einfach, eigene Überspringungsdekoratoren zu erstellen, indem ein Dekorator erstellt wird, der skip() für den Test aufruft, wenn er übersprungen werden soll. Dieser Dekorator überspringt den Test, es sei denn, das übergebene Objekt hat ein bestimmtes Attribut

def skipUnlessHasattr(obj, attr):
    if hasattr(obj, attr):
        return lambda func: func
    return unittest.skip("{!r} doesn't have {!r}".format(obj, attr))

Die folgenden Dekoratoren und Ausnahmen implementieren das Überspringen von Tests und erwartete Fehler

@unittest.skip(reason)¶: Überspringt den dekorierten Test bedingungslos. reason sollte beschreiben, warum der Test übersprungen wird.

@unittest.skipIf(condition, reason)¶: Überspringt den dekorierten Test, wenn condition wahr ist.

@unittest.skipUnless(condition, reason)¶: Überspringt den dekorierten Test, es sei denn, condition ist wahr.

@unittest.expectedFailure¶: Markiert den Test als erwarteten Fehler oder unerwartetes Ergebnis. Wenn der Test fehlschlägt oder einen Fehler auslöst, wird er als Erfolg gewertet. Wenn der Test erfolgreich ist, wird er als Fehler gewertet.

exception unittest.SkipTest(reason)¶

Diese Ausnahme wird ausgelöst, um einen Test zu überspringen.

Normalerweise können Sie TestCase.skipTest() oder einen der Überspringungsdekoratoren verwenden, anstatt diese direkt auszulösen.

Übersprungene Tests werden nicht mit setUp() oder tearDown() ausgeführt. Übersprungene Klassen werden nicht mit setUpClass() oder tearDownClass() ausgeführt. Übersprungene Module werden nicht mit setUpModule() oder tearDownModule() ausgeführt.

Unterscheiden von Testiterationen mithilfe von Subtests¶

Hinzugefügt in Version 3.4.

Wenn es sehr kleine Unterschiede zwischen Ihren Tests gibt, zum Beispiel einige Parameter, ermöglicht unittest Ihnen, diese innerhalb des Körpers einer Testmethode mithilfe des subTest() Kontextmanagers zu unterscheiden.

Zum Beispiel wird der folgende 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)

die folgende Ausgabe erzeugen

======================================================================
FAIL: test_even (__main__.NumbersTest.test_even) (i=1)
Test that numbers between 0 and 5 are all even.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 11, in test_even
    self.assertEqual(i % 2, 0)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 1 != 0

======================================================================
FAIL: test_even (__main__.NumbersTest.test_even) (i=3)
Test that numbers between 0 and 5 are all even.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 11, in test_even
    self.assertEqual(i % 2, 0)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 1 != 0

======================================================================
FAIL: test_even (__main__.NumbersTest.test_even) (i=5)
Test that numbers between 0 and 5 are all even.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 11, in test_even
    self.assertEqual(i % 2, 0)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 1 != 0

Ohne die Verwendung eines Subtests würde die Ausführung nach dem ersten Fehler stoppen, und der Fehler wäre schwerer zu diagnostizieren, da der Wert von i nicht angezeigt würde

======================================================================
FAIL: test_even (__main__.NumbersTest.test_even)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 32, in test_even
    self.assertEqual(i % 2, 0)
AssertionError: 1 != 0

Klassen und Funktionen¶

Dieser Abschnitt beschreibt ausführlich die API von unittest.

Testfälle¶

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

Instanzen der TestCase-Klasse stellen die logischen Testeinheiten im unittest-Universum dar. Diese Klasse ist als Basisklasse gedacht, wobei spezifische Tests von konkreten Unterklassen implementiert werden. Diese Klasse implementiert die Schnittstelle, die vom Testrunner benötigt wird, um die Tests auszuführen, und Methoden, die der Testcode verwenden kann, um verschiedene Arten von Fehlern zu überprüfen und zu melden.

Jede Instanz von TestCase führt eine einzige Basismethode aus: die Methode mit dem Namen methodName. In den meisten Anwendungen von TestCase werden Sie weder den methodName ändern noch die Standardmethode runTest() neu implementieren.

Geändert in Version 3.2: TestCase kann erfolgreich instanziiert werden, ohne einen methodName anzugeben. Dies erleichtert das Experimentieren mit TestCase vom interaktiven Interpreter aus.

TestCase-Instanzen stellen drei Gruppen von Methoden zur Verfügung: eine Gruppe zur Ausführung des Tests, eine weitere, die von der Testimplementierung zur Überprüfung von Bedingungen und Meldung von Fehlern verwendet wird, und einige Abfragemethoden, die das Sammeln von Informationen über den Test selbst ermöglichen.

Methoden in der ersten Gruppe (Ausführung des Tests) sind

setUp()¶: Methode, die aufgerufen wird, um das Test-Fixture vorzubereiten. Diese wird unmittelbar vor dem Aufruf der Testmethode aufgerufen; mit Ausnahme von AssertionError oder SkipTest wird jede von dieser Methode ausgelöste Ausnahme als Fehler und nicht als Testfehler betrachtet. Die Standardimplementierung tut nichts.

tearDown()¶: Methode, die unmittelbar nach dem Aufruf der Testmethode und der Aufzeichnung des Ergebnisses aufgerufen wird. Dies geschieht auch dann, wenn die Testmethode eine Ausnahme ausgelöst hat, sodass die Implementierung in Unterklassen möglicherweise besonders sorgfältig auf den internen Zustand achten muss. Jede von dieser Methode ausgelöste Ausnahme, mit Ausnahme von AssertionError oder SkipTest, wird als zusätzlicher Fehler und nicht als Testfehler betrachtet (wodurch die Gesamtzahl der gemeldeten Fehler erhöht wird). Diese Methode wird nur aufgerufen, wenn setUp() erfolgreich war, unabhängig vom Ergebnis der Testmethode. Die Standardimplementierung tut nichts.

setUpClass()¶

Eine Klassenmethode, die vor der Ausführung von Tests in einer einzelnen Klasse aufgerufen wird. setUpClass wird mit der Klasse als einzigem Argument aufgerufen und muss als classmethod() dekoriert sein.

@classmethod
def setUpClass(cls):
    ...

Weitere Details finden Sie unter Klassen- und Modulfixtures.

Hinzugefügt in Version 3.2.

tearDownClass()¶

Eine Klassenmethode, die nach der Ausführung von Tests in einer einzelnen Klasse aufgerufen wird. tearDownClass wird mit der Klasse als einzigem Argument aufgerufen und muss als classmethod() dekoriert sein.

@classmethod
def tearDownClass(cls):
    ...

Weitere Details finden Sie unter Klassen- und Modulfixtures.

Hinzugefügt in Version 3.2.

run(result=None)¶

Führt den Test aus und sammelt das Ergebnis im als result übergebenen TestResult-Objekt. Wenn result weggelassen wird oder None ist, wird ein temporäres Ergebnisobjekt erstellt (durch Aufruf der Methode defaultTestResult()) und verwendet. Das Ergebnisobjekt wird an den Aufrufer von run() zurückgegeben.

Der gleiche Effekt kann erzielt werden, indem einfach die TestCase-Instanz aufgerufen wird.

Geändert in Version 3.3: Frühere Versionen von run gaben das Ergebnis nicht zurück. Ebenso wenig der Aufruf einer Instanz.

skipTest(reason)¶: Der Aufruf dieser Methode während einer Testmethode oder setUp() überspringt den aktuellen Test. Weitere Informationen finden Sie unter Tests und erwartete Fehler überspringen.

Hinzugefügt in Version 3.1.

subTest(msg=None, **params)¶

Gibt einen Kontextmanager zurück, der den eingeschlossenen Codeblock als Subtest ausführt. msg und params sind optionale, beliebige Werte, die angezeigt werden, wenn ein Subtest fehlschlägt, was eine klare Identifizierung ermöglicht.

Ein Testfall kann eine beliebige Anzahl von Subtest-Deklarationen enthalten, und diese können beliebig verschachtelt werden.

Weitere Informationen finden Sie unter Unterscheiden von Testiterationen mithilfe von Subtests.

Hinzugefügt in Version 3.4.

debug()¶: Führt den Test aus, ohne das Ergebnis zu sammeln. Dies ermöglicht es, dass von dem Test ausgelöste Ausnahmen an den Aufrufer weitergegeben werden, und kann zur Unterstützung der Ausführung von Tests unter einem Debugger verwendet werden.

Die Klasse TestCase bietet mehrere Assert-Methoden zum Überprüfen und Melden von Fehlern. Die folgende Tabelle listet die gebräuchlichsten Methoden auf (weitere Assert-Methoden finden Sie in den folgenden Tabellen).

Methode	Prüft, dass	Neu in
`assertEqual(a, b)`	`a == b`
`assertNotEqual(a, b)`	`a != b`
`assertTrue(x)`	`bool(x) ist True`
`assertFalse(x)`	`bool(x) ist False`
`assertIs(a, b)`	`a ist b`	3.1
`assertIsNot(a, b)`	`a ist nicht b`	3.1
`assertIsNone(x)`	`x ist None`	3.1
`assertIsNotNone(x)`	`x ist nicht None`	3.1
`assertIn(a, b)`	`a in b`	3.1
`assertNotIn(a, b)`	`a nicht in b`	3.1
`assertIsInstance(a, b)`	`isinstance(a, b)`	3.2
`assertNotIsInstance(a, b)`	`nicht isinstance(a, b)`	3.2
`assertIsSubclass(a, b)`	`issubclass(a, b)`	3.14
`assertNotIsSubclass(a, b)`	`nicht issubclass(a, b)`	3.14

Alle Assert-Methoden akzeptieren ein Argument msg, das, wenn es angegeben wird, als Fehlermeldung bei einem Fehler verwendet wird (siehe auch longMessage). Beachten Sie, dass das Schlüsselwortargument msg nur für assertRaises(), assertRaisesRegex(), assertWarns(), assertWarnsRegex() übergeben werden kann, wenn diese als Kontextmanager verwendet werden.

assertEqual(first, second, msg=None)¶

Prüft, ob first und second gleich sind. Wenn die Werte nicht gleich sind, schlägt der Test fehl.

Darüber hinaus, wenn first und second vom exakt gleichen Typ sind und einer von list, tuple, dict, set, frozenset oder str oder einem beliebigen Typ, den eine Unterklasse bei addTypeEqualityFunc() registriert, wird die typspezifische Gleichheitsfunktion aufgerufen, um eine nützlichere Standardfehlermeldung zu generieren (siehe auch die Liste der typspezifischen Methoden).

Geändert in Version 3.1: Hinzufügen des automatischen Aufrufs der typspezifischen Gleichheitsfunktion.

Geändert in Version 3.2: assertMultiLineEqual() als Standard-Ty-Gleichheitsfunktion für den Vergleich von Zeichenketten hinzugefügt.

assertNotEqual(first, second, msg=None)¶: Prüft, ob first und second nicht gleich sind. Wenn die Werte gleich sind, schlägt der Test fehl.

assertTrue(expr, msg=None)¶

assertFalse(expr, msg=None)¶

Prüft, ob expr wahr (oder falsch) ist.

Beachten Sie, dass dies äquivalent zu bool(expr) ist True und nicht zu expr ist True ist (verwenden Sie assertIs(expr, True) für Letzteres). Diese Methode sollte auch vermieden werden, wenn spezifischere Methoden verfügbar sind (z. B. assertEqual(a, b) anstelle von assertTrue(a == b)), da sie im Fehlerfall eine bessere Fehlermeldung liefern.

assertIs(first, second, msg=None)¶
assertIsNot(first, second, msg=None)¶: Prüft, ob first und second dasselbe Objekt sind (oder nicht sind).

Hinzugefügt in Version 3.1.

assertIsNone(expr, msg=None)¶
assertIsNotNone(expr, msg=None)¶: Prüft, ob expr None ist (oder nicht ist).

Hinzugefügt in Version 3.1.

assertIn(member, container, msg=None)¶
assertNotIn(member, container, msg=None)¶: Prüft, ob member in container ist (oder nicht).

Hinzugefügt in Version 3.1.

assertIsInstance(obj, cls, msg=None)¶
assertNotIsInstance(obj, cls, msg=None)¶: Prüft, ob obj eine Instanz von cls ist (oder nicht ist) (wobei cls eine Klasse oder ein Tupel von Klassen sein kann, wie von isinstance() unterstützt wird). Um den exakten Typ zu überprüfen, verwenden Sie assertIs(type(obj), cls).

Hinzugefügt in Version 3.2.

assertIsSubclass(cls, superclass, msg=None)¶
assertNotIsSubclass(cls, superclass, msg=None)¶: Prüft, ob cls eine Unterklasse von superclass ist (oder nicht ist) (wobei superclass eine Klasse oder ein Tupel von Klassen sein kann, wie von issubclass() unterstützt wird). Um den exakten Typ zu überprüfen, verwenden Sie assertIs(cls, superclass).

Hinzugefügt in Version 3.14.

Es ist auch möglich, die Erzeugung von Ausnahmen, Warnungen und Log-Nachrichten mit den folgenden Methoden zu überprüfen

Methode	Prüft, dass	Neu in
`assertRaises(exc, fun, args, *kwds)`	`fun(args, kwds)` löst exc* aus
`assertRaisesRegex(exc, r, fun, args, *kwds)`	`fun(args, kwds)` löst exc* aus und die Nachricht stimmt mit dem Regex r überein	3.1
`assertWarns(warn, fun, args, *kwds)`	`fun(args, kwds)` löst warn* aus	3.2
`assertWarnsRegex(warn, r, fun, args, *kwds)`	`fun(args, kwds)` löst warn* aus und die Nachricht stimmt mit dem Regex r überein	3.2
`assertLogs(logger, level)`	Der `with`-Block loggt auf logger mit der minimalen level	3.4
`assertNoLogs(logger, level)`	Der `with`-Block loggt nicht auf logger mit der minimalen level	3.10

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

assertRaises(exception, *, msg=None)

Prüft, ob eine Ausnahme ausgelöst wird, wenn callable mit beliebigen Positions- oder Schlüsselwortargumenten aufgerufen wird, die ebenfalls an assertRaises() übergeben werden. Der Test ist bestanden, wenn exception ausgelöst wird, es ist ein Fehler, wenn eine andere Ausnahme ausgelöst wird, oder er schlägt fehl, wenn keine Ausnahme ausgelöst wird. Um eine beliebige Ausnahme aus einer Gruppe von Ausnahmen abzufangen, kann ein Tupel, das die Ausnahme-Klassen enthält, als exception übergeben werden.

Wenn nur die Argumente exception und möglicherweise msg angegeben sind, wird ein Kontextmanager zurückgegeben, sodass der zu testende Code inline und nicht als Funktion geschrieben werden kann.

with self.assertRaises(SomeException):
    do_something()

Bei Verwendung als Kontextmanager akzeptiert assertRaises() das zusätzliche Schlüsselwortargument msg.

Der Kontextmanager speichert das abgefangene Ausnahmeobjekt in seinem exception-Attribut. Dies kann nützlich sein, wenn die Absicht darin besteht, zusätzliche Überprüfungen an der ausgelösten Ausnahme durchzuführen.

with self.assertRaises(SomeException) as cm:
    do_something()

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

Geändert in Version 3.1: Hinzufügen der Möglichkeit, assertRaises() als Kontextmanager zu verwenden.

Geändert in Version 3.2: Hinzufügen des exception-Attributs.

Geändert in Version 3.3: Hinzufügen des msg-Schlüsselwortarguments bei Verwendung als Kontextmanager.

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

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

Wie assertRaises(), prüft aber auch, ob regex mit der Zeichenkettendarstellung der ausgelösten Ausnahme übereinstimmt. regex kann ein reguläres Ausdrucksobjekt oder eine Zeichenkette sein, die einen regulären Ausdruck für die Verwendung durch re.search() enthält. Beispiele

self.assertRaisesRegex(ValueError, "invalid literal for.*XYZ'$",
                       int, 'XYZ')

oder

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

Hinzugefügt in Version 3.1: Unter dem Namen assertRaisesRegexp hinzugefügt.

Geändert in Version 3.2: Umbenannt in assertRaisesRegex().

Geändert in Version 3.3: Hinzufügen des msg-Schlüsselwortarguments bei Verwendung als Kontextmanager.

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

assertWarns(warning, *, msg=None)

Prüft, ob eine Warnung ausgelöst wird, wenn callable mit beliebigen Positions- oder Schlüsselwortargumenten aufgerufen wird, die ebenfalls an assertWarns() übergeben werden. Der Test ist bestanden, wenn warning ausgelöst wird, und schlägt fehl, wenn nicht. Jede Ausnahme ist ein Fehler. Um eine beliebige Warnung aus einer Gruppe von Warnungen abzufangen, kann ein Tupel, das die Warnungsklassen enthält, als warnings übergeben werden.

Wenn nur die Argumente warning und möglicherweise msg übergeben werden, wird ein Kontextmanager zurückgegeben, sodass der zu testende Code inline und nicht als Funktion geschrieben werden kann

with self.assertWarns(SomeWarning):
    do_something()

Wenn assertWarns() als Kontextmanager verwendet wird, akzeptiert es das zusätzliche Schlüsselwortargument msg.

Der Kontextmanager speichert das abgefangene Warnungsobjekt in seinem Attribut warning und die Quellzeile, die die Warnungen ausgelöst hat, in den Attributen filename und lineno. Dies kann nützlich sein, wenn die Absicht besteht, zusätzliche Überprüfungen der abgefangenen Warnung durchzuführen

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

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

Diese Methode funktioniert unabhängig von den aktiven Warnungsfiltern, wenn sie aufgerufen wird.

Hinzugefügt in Version 3.2.

Geändert in Version 3.3: Hinzufügen des msg-Schlüsselwortarguments bei Verwendung als Kontextmanager.

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

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

Ähnlich wie assertWarns(), testet aber auch, dass regex auf die Nachricht der ausgelösten Warnung passt. regex kann ein reguläres Ausdrucksobjekt oder ein String sein, der einen regulären Ausdruck enthält, der für die Verwendung mit re.search() geeignet ist. Beispiel

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

oder

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

Hinzugefügt in Version 3.2.

Geändert in Version 3.3: Hinzufügen des msg-Schlüsselwortarguments bei Verwendung als Kontextmanager.

assertLogs(logger=None, level=None)¶

Ein Kontextmanager, der testet, ob mindestens eine Nachricht auf dem logger oder einem seiner Kinder mit mindestens dem angegebenen level protokolliert wird.

Wenn angegeben, sollte logger ein logging.Logger-Objekt oder ein str mit dem Namen eines Loggers sein. Der Standardwert ist der Root-Logger, der alle Nachrichten abfängt, die nicht durch einen nicht-propagierenden Nachkommen-Logger blockiert wurden.

Wenn angegeben, sollte level entweder ein numerischer Logging-Level oder seine String-Entsprechung sein (z. B. entweder "ERROR" oder logging.ERROR). Der Standardwert ist logging.INFO.

Der Test ist erfolgreich, wenn mindestens eine Nachricht, die innerhalb des with-Blocks ausgegeben wird, den logger- und level-Bedingungen entspricht, andernfalls schlägt er fehl.

Das vom Kontextmanager zurückgegebene Objekt ist ein Aufzeichnungshilfe, das die übereinstimmenden Log-Nachrichten verfolgt. Es hat zwei Attribute

records¶: Eine Liste von logging.LogRecord-Objekten der übereinstimmenden Log-Nachrichten.

output¶: Eine Liste von str-Objekten mit der formatierten Ausgabe übereinstimmender Nachrichten.

Beispiel

with self.assertLogs('foo', level='INFO') as cm:
    logging.getLogger('foo').info('first message')
    logging.getLogger('foo.bar').error('second message')
self.assertEqual(cm.output, ['INFO:foo:first message',
                             'ERROR:foo.bar:second message'])

Hinzugefügt in Version 3.4.

assertNoLogs(logger=None, level=None)¶

Ein Kontextmanager, der testet, dass keine Nachrichten auf dem logger oder einem seiner Kinder mit mindestens dem angegebenen level protokolliert werden.

Wenn angegeben, sollte logger ein logging.Logger-Objekt oder ein str mit dem Namen eines Loggers sein. Der Standardwert ist der Root-Logger, der alle Nachrichten abfängt.

Wenn angegeben, sollte level entweder ein numerischer Logging-Level oder seine String-Entsprechung sein (z. B. entweder "ERROR" oder logging.ERROR). Der Standardwert ist logging.INFO.

Im Gegensatz zu assertLogs() wird vom Kontextmanager nichts zurückgegeben.

Hinzugefügt in Version 3.10.

Es gibt auch andere Methoden, die für spezifischere Prüfungen verwendet werden, wie z. B.

Methode	Prüft, dass	Neu in
`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)`	`not r.search(s)`	3.2
`assertCountEqual(a, b)`	a und b haben die gleichen Elemente in der gleichen Anzahl, unabhängig von ihrer Reihenfolge.	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)¶

Testet, ob first und second ungefähr gleich (oder nicht ungefähr gleich) sind, indem die Differenz berechnet, auf die angegebene Anzahl von Dezimalstellen (standardmäßig 7) gerundet und mit Null verglichen wird. Beachten Sie, dass diese Methoden die Werte auf die angegebene Anzahl von Dezimalstellen runden (d. h. wie die Funktion round()) und nicht auf signifikante Ziffern.

Wenn delta anstelle von places angegeben wird, muss die Differenz zwischen first und second kleiner oder gleich (oder größer als) delta sein.

Die Angabe von sowohl delta als auch places löst einen TypeError aus.

Geändert in Version 3.2: assertAlmostEqual() berücksichtigt automatisch fast gleiche Objekte, die gleich verglichen werden. assertNotAlmostEqual() schlägt fehl, wenn die Objekte gleich verglichen werden. Das Schlüsselwortargument delta wurde hinzugefügt.

assertGreater(first, second, msg=None)¶

assertGreaterEqual(first, second, msg=None)¶

assertLess(first, second, msg=None)¶

assertLessEqual(first, second, msg=None)¶

Testet, ob first größer, größer oder gleich, kleiner oder kleiner oder gleich second ist, je nach Methodenname. Andernfalls schlägt der Test fehl.

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

Hinzugefügt in Version 3.1.

assertRegex(text, regex, msg=None)¶
assertNotRegex(text, regex, msg=None)¶: Testet, ob eine regex-Suche text übereinstimmt (oder nicht übereinstimmt). Im Fehlerfall enthält die Fehlermeldung das Muster und den text (oder das Muster und den Teil des text, der unerwartet übereinstimmte). regex kann ein reguläres Ausdrucksobjekt oder ein String sein, der einen regulären Ausdruck enthält, der für die Verwendung mit re.search() geeignet ist.

Hinzugefügt in Version 3.1: Unter dem Namen assertRegexpMatches hinzugefügt.

Geändert in Version 3.2: Die Methode assertRegexpMatches() wurde in assertRegex() umbenannt.

Hinzugefügt in Version 3.2: assertNotRegex().

assertCountEqual(first, second, msg=None)¶

Testet, ob die Sequenz first die gleichen Elemente wie second enthält, unabhängig von ihrer Reihenfolge. Wenn dies nicht der Fall ist, wird eine Fehlermeldung generiert, die die Unterschiede zwischen den Sequenzen auflistet.

Duplikate Elemente werden beim Vergleichen von first und second nicht ignoriert. Es wird überprüft, ob jedes Element in beiden Sequenzen die gleiche Anzahl hat. Entspricht: assertEqual(Counter(list(first)), Counter(list(second))), funktioniert aber auch mit Sequenzen von nicht hashbaren Objekten.

Hinzugefügt in Version 3.2.

assertStartsWith(s, prefix, msg=None)¶

assertNotStartsWith(s, prefix, msg=None)¶: Testet, ob die Unicode- oder Byte-Zeichenkette s mit einem prefix beginnt (oder nicht beginnt). prefix kann auch ein Tupel von Zeichenketten sein, die ausprobiert werden sollen.

Hinzugefügt in Version 3.14.

assertEndsWith(s, suffix, msg=None)¶

assertNotEndsWith(s, suffix, msg=None)¶: Testet, ob die Unicode- oder Byte-Zeichenkette s mit einem suffix endet (oder nicht endet). suffix kann auch ein Tupel von Zeichenketten sein, die ausprobiert werden sollen.

Hinzugefügt in Version 3.14.

assertHasAttr(obj, name, msg=None)¶

assertNotHasAttr(obj, name, msg=None)¶: Testet, ob das Objekt obj ein Attribut name hat (oder nicht hat).

Hinzugefügt in Version 3.14.

Die Methode assertEqual() leitet die Gleichheitsprüfung für Objekte desselben Typs an verschiedene typspezifische Methoden weiter. Diese Methoden sind für die meisten eingebauten Typen bereits implementiert, aber es ist auch möglich, neue Methoden mit addTypeEqualityFunc() zu registrieren.

addTypeEqualityFunc(typeobj, function)¶: Registriert eine typspezifische Methode, die von assertEqual() aufgerufen wird, um zu prüfen, ob zwei Objekte genau desselben typeobj (nicht Unterklassen) gleich sind. function muss zwei Positionsargumente und ein drittes msg=None-Schlüsselwortargument akzeptieren, genau wie assertEqual(). Sie muss self.failureException(msg) auslösen, wenn eine Ungleichheit zwischen den ersten beiden Parametern erkannt wird – möglicherweise unter Angabe nützlicher Informationen und Erläuterung der Ungleichheiten in der Fehlermeldung.

Hinzugefügt in Version 3.1.

Die Liste der typspezifischen Methoden, die automatisch von assertEqual() verwendet werden, ist in der folgenden Tabelle zusammengefasst. Beachten Sie, dass diese Methoden normalerweise nicht direkt aufgerufen werden müssen.

Methode	Verwendet zum Vergleichen	Neu in
`assertMultiLineEqual(a, b)`	Strings	3.1
`assertSequenceEqual(a, b)`	Sequenzen	3.1
`assertListEqual(a, b)`	Listen	3.1
`assertTupleEqual(a, b)`	Tupel	3.1
`assertSetEqual(a, b)`	Sets oder Frozensets	3.1
`assertDictEqual(a, b)`	Dicts	3.1

assertMultiLineEqual(first, second, msg=None)¶: Testet, ob der mehrzeilige String first mit dem String second übereinstimmt. Wenn nicht, wird eine Differenz der beiden Strings, die die Unterschiede hervorhebt, in die Fehlermeldung aufgenommen. Diese Methode wird standardmäßig beim Vergleichen von Strings mit assertEqual() verwendet.

Hinzugefügt in Version 3.1.

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

Testet, ob zwei Sequenzen gleich sind. Wenn ein seq_type angegeben wird, müssen sowohl first als auch second Instanzen von seq_type sein, andernfalls wird ein Fehler ausgelöst. Wenn die Sequenzen unterschiedlich sind, wird eine Fehlermeldung konstruiert, die die Unterschiede zwischen beiden zeigt.

Diese Methode wird nicht direkt von assertEqual() aufgerufen, sondern wird zur Implementierung von assertListEqual() und assertTupleEqual() verwendet.

Hinzugefügt in Version 3.1.

assertListEqual(first, second, msg=None)¶
assertTupleEqual(first, second, msg=None)¶: Testet, ob zwei Listen oder Tupel gleich sind. Wenn nicht, wird eine Fehlermeldung erstellt, die nur die Unterschiede zwischen den beiden anzeigt. Ein Fehler wird auch ausgelöst, wenn einer der Parameter vom falschen Typ ist. Diese Methoden werden standardmäßig beim Vergleichen von Listen oder Tupeln mit assertEqual() verwendet.

Hinzugefügt in Version 3.1.

assertSetEqual(first, second, msg=None)¶

Testet, ob zwei Sets gleich sind. Wenn nicht, wird eine Fehlermeldung erstellt, die die Unterschiede zwischen den Sets auflistet. Diese Methode wird standardmäßig beim Vergleichen von Sets oder Frozensets mit assertEqual() verwendet.

Schlägt fehl, wenn first oder second keine set.difference() Methode hat.

Hinzugefügt in Version 3.1.

assertDictEqual(first, second, msg=None)¶: Testet, ob zwei Wörterbücher gleich sind. Wenn nicht, wird eine Fehlermeldung erstellt, die die Unterschiede in den Wörterbüchern anzeigt. Diese Methode wird standardmäßig zum Vergleichen von Wörterbüchern in Aufrufen von assertEqual() verwendet.

Hinzugefügt in Version 3.1.

Schließlich bietet die TestCase die folgenden Methoden und Attribute

fail(msg=None)¶: Signalisiert bedingungslos einen Testfehler, mit msg oder None für die Fehlermeldung.

failureException¶: Dieses Klassenattribut gibt die Ausnahme an, die von der Testmethode ausgelöst wird. Wenn ein Test-Framework eine spezialisierte Ausnahme verwenden muss, möglicherweise um zusätzliche Informationen zu übermitteln, muss es diese Ausnahme unterklassifizieren, um mit dem Framework „fair zu spielen“. Der Anfangswert dieses Attributs ist AssertionError.

longMessage¶

Dieses Klassenattribut bestimmt, was passiert, wenn eine benutzerdefinierte Fehlermeldung als msg-Argument an einen fehlschlagenden assertXYY-Aufruf übergeben wird. True ist der Standardwert. In diesem Fall wird die benutzerdefinierte Meldung am Ende der Standardfehlermeldung angehängt. Wenn auf False gesetzt, ersetzt die benutzerdefinierte Meldung die Standardmeldung.

Die Klasseneinstellung kann in einzelnen Testmethoden überschrieben werden, indem ein Instanzattribut, self.longMessage, auf True oder False gesetzt wird, bevor die Assert-Methoden aufgerufen werden.

Die Klasseneinstellung wird vor jedem Testaufruf zurückgesetzt.

Hinzugefügt in Version 3.1.

maxDiff¶

Dieses Attribut steuert die maximale Länge von Diffs, die von Assert-Methoden ausgegeben werden, die Diffs bei einem Fehler berichten. Es ist standardmäßig auf 80*8 Zeichen eingestellt. Von diesem Attribut betroffene Assert-Methoden sind assertSequenceEqual() (einschließlich aller Sequenzvergleichsmethoden, die an sie delegieren), assertDictEqual() und assertMultiLineEqual().

Das Setzen von maxDiff auf None bedeutet, dass es keine maximale Länge für Diffs gibt.

Hinzugefügt in Version 3.2.

Test-Frameworks können die folgenden Methoden verwenden, um Informationen über den Test zu sammeln

countTestCases()¶: Gibt die Anzahl der von diesem Testobjekt dargestellten Tests zurück. Für TestCase-Instanzen ist dies immer 1.

defaultTestResult()¶

Gibt eine Instanz der Test-Ergebnisklasse zurück, die für diese Testfallklasse verwendet werden sollte (wenn keine andere Ergebnisinstanz an die Methode run() übergeben wird).

Für TestCase-Instanzen ist dies immer eine Instanz von TestResult; Unterklassen von TestCase sollten dies nach Bedarf überschreiben.

id()¶: Gibt eine Zeichenkette zurück, die den spezifischen Testfall identifiziert. Dies ist normalerweise der vollständige Name der Testmethode, einschließlich des Modul- und Klassennamens.

shortDescription()¶: Gibt eine Beschreibung des Tests zurück oder None, wenn keine Beschreibung angegeben wurde. Die Standardimplementierung dieser Methode gibt die erste Zeile des Docstrings der Testmethode zurück, falls verfügbar, oder None.

Geändert in Version 3.1: In 3.1 wurde dies geändert, um den Testnamen zur kurzen Beschreibung hinzuzufügen, auch wenn ein Docstring vorhanden war. Dies verursachte Kompatibilitätsprobleme mit unittest-Erweiterungen, und das Hinzufügen des Testnamens wurde in Python 3.2 in TextTestResult verschoben.

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

Fügt eine Funktion hinzu, die nach tearDown() aufgerufen wird, um während des Tests verwendete Ressourcen zu bereinigen. Funktionen werden in umgekehrter Reihenfolge zu ihrer Hinzufügung aufgerufen (LIFO). Sie werden mit allen Argumenten und Schlüsselwortargumenten aufgerufen, die beim Hinzufügen an addCleanup() übergeben wurden.

Wenn setUp() fehlschlägt, was bedeutet, dass tearDown() nicht aufgerufen wird, werden alle hinzugefügten Bereinigungsfunktionen trotzdem aufgerufen.

Hinzugefügt in Version 3.1.

enterContext(cm)¶: Tritt in den bereitgestellten Kontextmanager ein. Bei Erfolg wird seine __exit__()-Methode als Bereinigungsfunktion über addCleanup() hinzugefügt, und das Ergebnis der __enter__()-Methode wird zurückgegeben.

Hinzugefügt in Version 3.11.

doCleanups()¶

Diese Methode wird bedingungslos nach tearDown() aufgerufen, oder nach setUp(), wenn setUp() eine Ausnahme auslöst.

Sie ist dafür verantwortlich, alle von addCleanup() hinzugefügten Bereinigungsfunktionen aufzurufen. Wenn Sie möchten, dass Bereinigungsfunktionen *vor* tearDown() aufgerufen werden, können Sie doCleanups() selbst aufrufen.

doCleanups() holt Methoden nacheinander vom Stapel der Bereinigungsfunktionen, sodass sie jederzeit aufgerufen werden kann.

Hinzugefügt in Version 3.1.

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

Fügt eine Funktion hinzu, die nach tearDownClass() aufgerufen wird, um während der Testklasse verwendete Ressourcen zu bereinigen. Funktionen werden in umgekehrter Reihenfolge zu ihrer Hinzufügung aufgerufen (LIFO). Sie werden mit allen Argumenten und Schlüsselwortargumenten aufgerufen, die beim Hinzufügen an addClassCleanup() übergeben wurden.

Wenn setUpClass() fehlschlägt, was bedeutet, dass tearDownClass() nicht aufgerufen wird, werden alle hinzugefügten Bereinigungsfunktionen trotzdem aufgerufen.

Hinzugefügt in Version 3.8.

classmethod enterClassContext(cm)¶: Tritt in den bereitgestellten Kontextmanager ein. Bei Erfolg wird seine __exit__()-Methode als Bereinigungsfunktion über addClassCleanup() hinzugefügt, und das Ergebnis der __enter__()-Methode wird zurückgegeben.

Hinzugefügt in Version 3.11.

classmethod doClassCleanups()¶

Diese Methode wird bedingungslos nach tearDownClass() aufgerufen, oder nach setUpClass(), wenn setUpClass() eine Ausnahme auslöst.

Sie ist dafür verantwortlich, alle von addClassCleanup() hinzugefügten Bereinigungsfunktionen aufzurufen. Wenn Sie möchten, dass Bereinigungsfunktionen *vor* tearDownClass() aufgerufen werden, können Sie doClassCleanups() selbst aufrufen.

doClassCleanups() holt Methoden nacheinander vom Stapel der Bereinigungsfunktionen, sodass sie jederzeit aufgerufen werden kann.

Hinzugefügt in Version 3.8.

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

Diese Klasse bietet eine API, die TestCase ähnelt und auch Koroutinen als Testfunktionen akzeptiert.

Hinzugefügt in Version 3.8.

loop_factory¶: Die an asyncio.Runner übergebene loop_factory. Überschreiben Sie in Unterklassen mit asyncio.EventLoop, um die Verwendung des asyncio-Richtliniensystems zu vermeiden.

Hinzugefügt in Version 3.13.

async asyncSetUp()¶: Methode, die aufgerufen wird, um die Testfixture vorzubereiten. Dies geschieht nach setUp(). Dies wird unmittelbar vor dem Aufruf der Testmethode aufgerufen; mit Ausnahme von AssertionError oder SkipTest werden alle von dieser Methode ausgelösten Ausnahmen als Fehler und nicht als Testfehler betrachtet. Die Standardimplementierung tut nichts.

async asyncTearDown()¶: Methode, die unmittelbar nach dem Aufruf der Testmethode und der Aufzeichnung des Ergebnisses aufgerufen wird. Dies geschieht vor tearDown(). Sie wird auch dann aufgerufen, wenn die Testmethode eine Ausnahme auslöst. Die Implementierung in Unterklassen muss daher möglicherweise besonders sorgfältig auf den internen Zustand prüfen. Jede Ausnahme, mit Ausnahme von AssertionError oder SkipTest, die von dieser Methode ausgelöst wird, wird als zusätzlicher Fehler und nicht als Testfehler betrachtet (wodurch sich die Gesamtzahl der gemeldeten Fehler erhöht). Diese Methode wird nur aufgerufen, wenn asyncSetUp() erfolgreich war, unabhängig vom Ergebnis der Testmethode. Die Standardimplementierung tut nichts.

addAsyncCleanup(function, /, *args, **kwargs)¶: Diese Methode akzeptiert eine Koroutine, die als Bereinigungsfunktion verwendet werden kann.

async enterAsyncContext(cm)¶: Tritt in den bereitgestellten asynchronen Kontextmanager ein. Bei Erfolg wird seine __aexit__()-Methode als Bereinigungsfunktion über addAsyncCleanup() hinzugefügt, und das Ergebnis der __aenter__()-Methode wird zurückgegeben.

Hinzugefügt in Version 3.11.

run(result=None)¶: Richtet eine neue Ereignisschleife ein, um den Test auszuführen, und sammelt das Ergebnis im als result übergebenen TestResult-Objekt. Wenn result weggelassen wird oder None ist, wird ein temporäres Ergebnisobjekt erstellt (durch Aufruf der Methode defaultTestResult()) und verwendet. Das Ergebnisobjekt wird an den Aufrufer von run() zurückgegeben. Am Ende des Tests werden alle Tasks in der Ereignisschleife abgebrochen.

Ein Beispiel zur Veranschaulichung der Reihenfolge

from unittest import IsolatedAsyncioTestCase

events = []


class 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(response.status_code, 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")

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

Nach Ausführung des Tests würde events ["setUp", "asyncSetUp", "test_response", "asyncTearDown", "tearDown", "cleanup"] enthalten.

class unittest.FunctionTestCase(testFunc, setUp=None, tearDown=None, description=None)¶: Diese Klasse implementiert den Teil der TestCase-Schnittstelle, die es dem Test-Runner ermöglicht, den Test anzutreiben, bietet aber nicht die Methoden, die der Testcode zum Prüfen und Melden von Fehlern verwenden kann. Dies wird verwendet, um Testfälle aus Legacy-Testcode zu erstellen, wodurch dieser in ein auf unittest basierendes Testframework integriert werden kann.

Tests gruppieren¶

class unittest.TestSuite(tests=())¶

Diese Klasse stellt eine Aggregation einzelner Testfälle und Test-Suiten dar. Die Klasse stellt die Schnittstelle bereit, die der Test-Runner benötigt, um sie wie jeden anderen Testfall auszuführen. Das Ausführen einer TestSuite-Instanz ist dasselbe wie das Iterieren über die Suite und das individuelle Ausführen jedes Tests.

Wenn tests angegeben ist, muss es ein Iterable von einzelnen Testfällen oder anderen Test-Suiten sein, die zum anfänglichen Aufbau der Suite verwendet werden. Es werden zusätzliche Methoden bereitgestellt, um später Testfälle und Suiten zur Sammlung hinzuzufügen.

TestSuite-Objekte verhalten sich weitgehend wie TestCase-Objekte, außer dass sie tatsächlich keinen Test implementieren. Stattdessen werden sie verwendet, um Tests in Gruppen von Tests zu aggregieren, die zusammen ausgeführt werden sollen. Einige zusätzliche Methoden sind verfügbar, um Tests zu TestSuite-Instanzen hinzuzufügen.

addTest(test)¶: Fügt einen TestCase oder eine TestSuite zur Suite hinzu.

addTests(tests)¶

Fügt alle Tests aus einem Iterable von TestCase- und TestSuite-Instanzen zu dieser Testsuite hinzu.

Dies entspricht dem Iterieren über tests und dem Aufrufen von addTest() für jedes Element.

TestSuite teilt die folgenden Methoden mit TestCase

run(result)¶: Führt die mit dieser Suite verbundenen Tests aus und sammelt das Ergebnis im als result übergebenen Test-Ergebnisobjekt. Beachten Sie, dass TestSuite.run(), im Gegensatz zu TestCase.run(), erfordert, dass das Ergebnisobjekt übergeben wird.

debug()¶: Führt die mit dieser Suite verbundenen Tests aus, ohne das Ergebnis zu sammeln. Dies ermöglicht es, dass Ausnahmen, die vom Test ausgelöst werden, an den Aufrufer weitergegeben werden, und kann verwendet werden, um das Ausführen von Tests unter einem Debugger zu unterstützen.

countTestCases()¶: Gibt die Anzahl der von diesem Testobjekt dargestellten Tests zurück, einschließlich aller einzelnen Tests und Unter-Suiten.

__iter__()¶: Tests, die von einer TestSuite gruppiert werden, werden immer über Iteration abgerufen. Unterklassen können Tests verzögert bereitstellen, indem sie __iter__() überschreiben. Beachten Sie, dass diese Methode mehrmals für eine einzelne Suite aufgerufen werden kann (z. B. beim Zählen von Tests oder beim Vergleichen auf Gleichheit), daher müssen die von wiederholten Iterationen vor TestSuite.run() zurückgegebenen Tests für jede Iteration gleich sein. Nach TestSuite.run() sollten Aufrufer sich nicht auf die von dieser Methode zurückgegebenen Tests verlassen, es sei denn, der Aufrufer verwendet eine Unterklasse, die TestSuite._removeTestAtIndex() überschreibt, um Testreferenzen beizubehalten.

Geändert in Version 3.2: In früheren Versionen rief TestSuite Tests direkt und nicht über Iteration ab, sodass das Überschreiben von __iter__() nicht ausreichte, um Tests bereitzustellen.

Geändert in Version 3.4: In früheren Versionen hielt TestSuite Referenzen auf jeden TestCase nach TestSuite.run(). Unterklassen können dieses Verhalten wiederherstellen, indem sie TestSuite._removeTestAtIndex() überschreiben.

Bei der typischen Verwendung eines TestSuite-Objekts wird die Methode run() von einem TestRunner und nicht vom Endbenutzer-Test-Harness aufgerufen.

Tests laden und ausführen¶

class unittest.TestLoader¶

Die Klasse TestLoader wird verwendet, um Test-Suiten aus Klassen und Modulen zu erstellen. Normalerweise ist es nicht notwendig, eine Instanz dieser Klasse zu erstellen; das Modul unittest stellt eine Instanz bereit, die als unittest.defaultTestLoader gemeinsam genutzt werden kann. Die Verwendung einer Unterklasse oder Instanz ermöglicht jedoch die Anpassung einiger konfigurierbarer Eigenschaften.

TestLoader-Objekte haben die folgenden Attribute

errors¶: Eine Liste von nicht-fatalen Fehlern, die beim Laden von Tests aufgetreten sind. Wird vom Lader zu keinem Zeitpunkt zurückgesetzt. Fatale Fehler werden durch die relevante Methode signalisiert, die eine Ausnahme an den Aufrufer auslöst. Nicht-fatale Fehler werden auch durch einen synthetischen Test signalisiert, der beim Ausführen den ursprünglichen Fehler auslöst.

Hinzugefügt in Version 3.5.

TestLoader-Objekte haben die folgenden Methoden

loadTestsFromTestCase(testCaseClass)¶

Gibt eine Suite aller Testfälle zurück, die in der von TestCase abgeleiteten Klasse testCaseClass enthalten sind.

Für jede Methode, deren Name von getTestCaseNames() ermittelt wird, wird eine Testinstanz erstellt. Standardmäßig sind dies Methodennamen, die mit test beginnen. Wenn getTestCaseNames() keine Methoden zurückgibt, aber die Methode runTest() implementiert ist, wird stattdessen eine einzelne Testinstanz für diese Methode erstellt.

loadTestsFromModule(module, *, pattern=None)¶

Gibt eine Suite aller Testfälle im angegebenen Modul zurück. Diese Methode sucht im module nach Klassen, die von TestCase abgeleitet sind, und erstellt für jede für die Klasse definierte Testmethode eine Instanz der Klasse.

Hinweis

Während die Verwendung einer Hierarchie von von TestCase abgeleiteten Klassen praktisch für die gemeinsame Nutzung von Fixtures und Hilfsfunktionen sein kann, funktioniert die Definition von Testmethoden in Basisklassen, die nicht direkt instanziiert werden sollen, mit dieser Methode nicht gut. Dies kann jedoch nützlich sein, wenn die Fixtures unterschiedlich sind und in Unterklassen definiert werden.

Wenn ein Modul eine Funktion load_tests bereitstellt, wird diese aufgerufen, um die Tests zu laden. Dies ermöglicht es Modulen, das Testladen anzupassen. Dies ist das load_tests-Protokoll. Das pattern-Argument wird als drittes Argument an load_tests übergeben.

Geändert in Version 3.2: Unterstützung für load_tests hinzugefügt.

Geändert in Version 3.5: Unterstützung für ein Keyword-only-Argument pattern wurde hinzugefügt.

Geändert in Version 3.12: Der undokumentierte und inoffizielle Parameter use_load_tests wurde entfernt.

loadTestsFromName(name, module=None)¶

Gibt eine Suite aller Testfälle zurück, basierend auf einem Zeichenkettenbezeichner.

Der Bezeichner name ist ein „punktierter Name“, der entweder zu einem Modul, einer Testfallklasse, einer Testmethode innerhalb einer Testfallklasse, einer TestSuite-Instanz oder einem aufrufbaren Objekt aufgelöst werden kann, das einen TestCase- oder TestSuite-Instanz zurückgibt. Diese Prüfungen werden in der aufgeführten Reihenfolge angewendet; das heißt, eine Methode in einer möglichen Testfallklasse wird als „eine Testmethode innerhalb einer Testfallklasse“ erkannt und nicht als „ein aufrufbares Objekt“.

Wenn Sie beispielsweise ein Modul SampleTests haben, das eine von TestCase abgeleitete Klasse SampleTestCase mit drei Testmethoden (test_one(), test_two() und test_three()) enthält, führt der Bezeichner 'SampleTests.SampleTestCase' dazu, dass diese Methode eine Suite zurückgibt, die alle drei Testmethoden ausführt. Die Verwendung des Bezeichners 'SampleTests.SampleTestCase.test_two' führt dazu, dass eine Testsuite zurückgegeben wird, die nur die Testmethode test_two() ausführt. Der Bezeichner kann sich auf Module und Pakete beziehen, die noch nicht importiert wurden; sie werden als Nebeneffekt importiert.

Die Methode löst optional name relativ zum angegebenen module auf.

Geändert in Version 3.5: Wenn während der Traversierung von name ein ImportError oder AttributeError auftritt, wird ein synthetischer Test zurückgegeben, der diesen Fehler beim Ausführen auslöst. Diese Fehler werden in den von self.errors gesammelten Fehlern enthalten.

loadTestsFromNames(names, module=None)¶: Ähnlich wie loadTestsFromName(), aber erwartet eine Sequenz von Namen anstelle eines einzelnen Namens. Der Rückgabewert ist eine Testsuite, die alle für jeden Namen definierten Tests unterstützt.

getTestCaseNames(testCaseClass)¶: Gibt eine sortierte Sequenz von Methodennamen zurück, die in testCaseClass gefunden wurden; dies sollte eine Unterklasse von TestCase sein.

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

Findet alle Testmodule, indem sie von Verzeichnis zu Verzeichnis rekursiv durchsucht werden, und gibt ein TestSuite-Objekt zurück, das diese enthält. Nur Testdateien, die dem pattern entsprechen, werden geladen. (Verwendet Shell-ähnliche Mustererkennung.) Nur Modulnamen, die importierbar sind (d.h. gültige Python-Bezeichner), werden geladen.

Alle Testmodule müssen vom obersten Level des Projekts importierbar sein. Wenn das Startverzeichnis nicht das oberste Level-Verzeichnis ist, muss top_level_dir separat angegeben werden.

Wenn der Import eines Moduls fehlschlägt, z. B. aufgrund eines Syntaxfehlers, wird dies als einzelner Fehler erfasst und die Suche wird fortgesetzt. Wenn der Importfehler darauf zurückzuführen ist, dass SkipTest ausgelöst wird, wird er als Überspringung anstelle eines Fehlers erfasst.

Wenn ein Paket (ein Verzeichnis, das eine Datei namens __init__.py enthält) gefunden wird, wird das Paket auf eine Funktion load_tests überprüft. Wenn diese existiert, wird sie als package.load_tests(loader, tests, pattern) aufgerufen. Die Testsuche stellt sicher, dass ein Paket während eines Aufrufs nur einmal auf Tests überprüft wird, auch wenn die Funktion load_tests selbst loader.discover aufruft.

Wenn load_tests existiert, rekursiert die Suche nicht in das Paket; load_tests ist für das Laden aller Tests im Paket verantwortlich.

Das Muster wird absichtlich nicht als Loader-Attribut gespeichert, damit Pakete die Suche selbst fortsetzen können.

top_level_dir wird intern gespeichert und als Standard für alle verschachtelten Aufrufe von discover() verwendet. Das heißt, wenn load_tests eines Pakets loader.discover() aufruft, muss dieses Argument nicht übergeben werden.

start_dir kann sowohl ein punktierter Modulname als auch ein Verzeichnis sein.

Hinzugefügt in Version 3.2.

Geändert in Version 3.4: Module, die SkipTest beim Import auslösen, werden als Überspringungen und nicht als Fehler erfasst.

start_dir kann ein Namespace-Paket sein.

Pfade werden vor dem Import sortiert, damit die Ausführungsreihenfolge gleich ist, auch wenn die Reihenfolge des zugrunde liegenden Dateisystems nicht vom Dateinamen abhängt.

Geändert in Version 3.5: Gefundene Pakete werden jetzt auf load_tests überprüft, unabhängig davon, ob ihr Pfad mit pattern übereinstimmt, da es unmöglich ist, dass ein Paketname mit dem Standardmuster übereinstimmt.

Geändert in Version 3.11: start_dir kann kein Namespace-Paket sein. Es ist seit Python 3.7 fehlerhaft und Python 3.11 entfernt es offiziell.

Geändert in Version 3.13: top_level_dir wird nur für die Dauer des discover-Aufrufs gespeichert.

Geändert in Version 3.14: start_dir kann wieder ein Namespace-Paket sein.

Die folgenden Attribute eines TestLoader können entweder durch Ableitung oder durch Zuweisung an eine Instanz konfiguriert werden.

testMethodPrefix¶

Zeichenkette, die das Präfix von Methodennamen angibt, die als Testmethoden interpretiert werden. Der Standardwert ist 'test'.

Dies wirkt sich auf getTestCaseNames() und alle loadTestsFrom* Methoden aus.

sortTestMethodsUsing¶: Funktion, die zum Vergleichen von Methodennamen beim Sortieren in getTestCaseNames() und allen loadTestsFrom* Methoden verwendet werden soll.

suiteClass¶

Aufrufbares Objekt, das eine Testsuite aus einer Liste von Tests erstellt. Es werden keine Methoden des resultierenden Objekts benötigt. Der Standardwert ist die TestSuite-Klasse.

Dies wirkt sich auf alle loadTestsFrom* Methoden aus.

testNamePatterns¶

Liste von Unix-Shell-ähnlichen Wildcard-Mustern für Testnamen, die von Testmethoden erfüllt werden müssen, um in Testsuiten aufgenommen zu werden (siehe Option -k).

Wenn dieses Attribut nicht None (Standard) ist, müssen alle Testmethoden, die in Testsuiten aufgenommen werden sollen, einem der Muster in dieser Liste entsprechen. Beachten Sie, dass Übereinstimmungen immer mit fnmatch.fnmatchcase() durchgeführt werden, daher müssen im Gegensatz zu Mustern, die an die Option -k übergeben werden, einfache Teilmuster mit *-Wildcards konvertiert werden.

Dies wirkt sich auf alle loadTestsFrom* Methoden aus.

Hinzugefügt in Version 3.7.

class unittest.TestResult¶

Diese Klasse wird verwendet, um Informationen darüber zu kompilieren, welche Tests erfolgreich waren und welche fehlgeschlagen sind.

Ein TestResult-Objekt speichert die Ergebnisse einer Reihe von Tests. Die Klassen TestCase und TestSuite stellen sicher, dass die Ergebnisse korrekt aufgezeichnet werden; Testautoren müssen sich keine Gedanken über die Aufzeichnung des Testergebnisses machen.

Test-Frameworks, die auf unittest aufbauen, möchten möglicherweise auf das TestResult-Objekt zugreifen, das durch Ausführen einer Reihe von Tests für Berichterstattungszwecke generiert wird; eine TestResult-Instanz wird von der Methode TestRunner.run() zu diesem Zweck zurückgegeben.

TestResult-Instanzen haben die folgenden Attribute, die für die Inspektion der Ergebnisse der Ausführung einer Reihe von Tests von Interesse sind.

errors¶: Eine Liste, die 2-Tupel von TestCase-Instanzen und Zeichenketten mit formatierten Tracebacks enthält. Jedes Tupel stellt einen Test dar, der eine unerwartete Ausnahme ausgelöst hat.

failures¶: Eine Liste, die 2-Tupel von TestCase-Instanzen und Zeichenketten mit formatierten Tracebacks enthält. Jedes Tupel stellt einen Test dar, bei dem ein Fehler explizit mit den assert*-Methoden signalisiert wurde.

skipped¶: Eine Liste, die 2-Tupel von TestCase-Instanzen und Zeichenketten mit dem Grund für die Überspringung des Tests enthält.

Hinzugefügt in Version 3.1.

expectedFailures¶: Eine Liste, die 2-Tupel von TestCase-Instanzen und Zeichenketten mit formatierten Tracebacks enthält. Jedes Tupel stellt einen erwarteten Fehler oder Ausfallfall der Testinstanz dar.

unexpectedSuccesses¶: Eine Liste, die TestCase-Instanzen enthält, die als erwartete Fehler markiert wurden, aber erfolgreich waren.

collectedDurations¶: Eine Liste, die 2-Tupel von Testfallnamen und Floats enthält, die die verstrichene Zeit jedes ausgeführten Tests darstellen.

Hinzugefügt in Version 3.12.

shouldStop¶: Wird auf True gesetzt, wenn die Ausführung von Tests durch stop() abgebrochen werden soll.

testsRun¶: Die Gesamtzahl der bisher ausgeführten Tests.

buffer¶: Wenn auf True gesetzt, werden sys.stdout und sys.stderr zwischen dem Aufruf von startTest() und stopTest() gepuffert. Gesammelte Ausgaben werden nur dann auf die tatsächlichen sys.stdout und sys.stderr ausgegeben, wenn der Test fehlschlägt oder Fehler verursacht. Jede Ausgabe wird auch an die Fehlermeldung / den Fehler angehängt.

Hinzugefügt in Version 3.2.

failfast¶: Wenn auf True gesetzt, wird stop() beim ersten Fehlschlag oder Fehler aufgerufen, wodurch der Testlauf abgebrochen wird.

Hinzugefügt in Version 3.2.

tb_locals¶: Wenn auf True gesetzt, werden lokale Variablen in Tracebacks angezeigt.

Hinzugefügt in Version 3.5.

wasSuccessful()¶: Gibt True zurück, wenn alle bisher ausgeführten Tests bestanden wurden, andernfalls gibt sie False zurück.

Geändert in Version 3.4: Gibt False zurück, wenn es unerwartete Erfolge (unexpectedSuccesses) bei Tests gab, die mit dem Dekorator expectedFailure() markiert waren.

stop()¶

Diese Methode kann aufgerufen werden, um zu signalisieren, dass die auszuführenden Tests abgebrochen werden sollen, indem das Attribut shouldStop auf True gesetzt wird. TestRunner-Objekte sollten diese Flagge berücksichtigen und zurückkehren, ohne zusätzliche Tests auszuführen.

Diese Funktion wird beispielsweise von der Klasse TextTestRunner verwendet, um das Test-Framework zu stoppen, wenn der Benutzer eine Unterbrechung von der Tastatur signalisiert. Interaktive Werkzeuge, die TestRunner-Implementierungen bereitstellen, können dies in ähnlicher Weise nutzen.

Die folgenden Methoden der Klasse TestResult werden verwendet, um die internen Datenstrukturen zu verwalten, und können in Unterklassen erweitert werden, um zusätzliche Berichterstattungsanforderungen zu unterstützen. Dies ist besonders nützlich beim Erstellen von Werkzeugen, die interaktive Berichterstattung unterstützen, während Tests ausgeführt werden.

startTest(test)¶: Wird aufgerufen, wenn die Testinstanz test kurz vor der Ausführung steht.

stopTest(test)¶: Wird aufgerufen, nachdem die Testinstanz test ausgeführt wurde, unabhängig vom Ergebnis.

startTestRun()¶: Wird einmal aufgerufen, bevor Tests ausgeführt werden.

Hinzugefügt in Version 3.1.

stopTestRun()¶: Wird einmal nach der Ausführung aller Tests aufgerufen.

Hinzugefügt in Version 3.1.

addError(test, err)¶

Wird aufgerufen, wenn die Testinstanz test eine unerwartete Ausnahme auslöst. err ist ein Tupel der Form, wie es von sys.exc_info() zurückgegeben wird: (type, value, traceback).

Die Standardimplementierung hängt ein Tupel (test, formatted_err) an das Attribut errors der Instanz an, wobei formatted_err ein formatierter Traceback ist, der von err abgeleitet wurde.

addFailure(test, err)¶

Wird aufgerufen, wenn die Testinstanz test einen Fehlschlag signalisiert. err ist ein Tupel der Form, wie es von sys.exc_info() zurückgegeben wird: (type, value, traceback).

Die Standardimplementierung hängt ein Tupel (test, formatted_err) an das Attribut failures der Instanz an, wobei formatted_err ein formatierter Traceback ist, der von err abgeleitet wurde.

addSuccess(test)¶

Wird aufgerufen, wenn die Testinstanz test erfolgreich war.

Die Standardimplementierung tut nichts.

addSkip(test, reason)¶

Wird aufgerufen, wenn die Testinstanz test übersprungen wird. reason ist der Grund für die Überspringung des Tests.

Die Standardimplementierung hängt ein Tupel (test, reason) an das Attribut skipped der Instanz an.

addExpectedFailure(test, err)¶

Wird aufgerufen, wenn die Testinstanz test fehlschlägt oder einen Fehler verursacht, aber mit dem Dekorator expectedFailure() markiert wurde.

Die Standardimplementierung hängt ein Tupel (test, formatted_err) an das Attribut expectedFailures der Instanz an, wobei formatted_err ein formatierter Traceback ist, der von err abgeleitet wurde.

addUnexpectedSuccess(test)¶

Wird aufgerufen, wenn die Testinstanz test mit dem Dekorator expectedFailure() markiert wurde, aber erfolgreich war.

Die Standardimplementierung hängt den Test an das Attribut unexpectedSuccesses der Instanz an.

addSubTest(test, subtest, outcome)¶

Wird aufgerufen, wenn ein Subtest beendet wird. test ist die Testinstanz, die der Testmethode entspricht. subtest ist eine benutzerdefinierte TestCase-Instanz, die den Subtest beschreibt.

Wenn outcome None ist, war der Subtest erfolgreich. Andernfalls ist er mit einer Ausnahme fehlgeschlagen, wobei outcome ein Tupel der Form ist, wie es von sys.exc_info() zurückgegeben wird: (type, value, traceback).

Die Standardimplementierung tut nichts, wenn das Ergebnis ein Erfolg ist, und zeichnet Subtestfehler als normale Fehler auf.

Hinzugefügt in Version 3.4.

addDuration(test, elapsed)¶: Wird aufgerufen, wenn die Testinstanz beendet wird. elapsed ist die Zeit in Sekunden und beinhaltet die Ausführung von Aufräumfunktionen.

Hinzugefügt in Version 3.12.

class unittest.TextTestResult(stream, descriptions, verbosity, *, durations=None)¶: Eine konkrete Implementierung von TestResult, die von TextTestRunner verwendet wird. Unterklassen sollten **kwargs akzeptieren, um die Kompatibilität bei Änderungen der Schnittstelle zu gewährleisten.

Hinzugefügt in Version 3.2.

Geändert in Version 3.12: Der Keyword-Parameter durations wurde hinzugefügt.

unittest.defaultTestLoader¶: Instanz der Klasse TestLoader, die geteilt werden soll. Wenn keine Anpassung des TestLoader erforderlich ist, kann diese Instanz anstelle von wiederholtem Erstellen neuer Instanzen verwendet werden.

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

Eine grundlegende Test-Runner-Implementierung, die Ergebnisse in einen Stream ausgibt. Wenn stream None ist (Standard), wird sys.stderr als Ausgabestrom verwendet. Diese Klasse verfügt über einige konfigurierbare Parameter, ist aber im Wesentlichen sehr einfach. Grafische Anwendungen, die Test-Suiten ausführen, sollten alternative Implementierungen bereitstellen. Solche Implementierungen sollten **kwargs als Schnittstelle akzeptieren, da sich die Schnittstelle zum Erstellen von Runnern ändert, wenn Funktionen zu unittest hinzugefügt werden.

Standardmäßig zeigt dieser Runner DeprecationWarning, PendingDeprecationWarning, ResourceWarning und ImportWarning an, auch wenn diese standardmäßig ignoriert werden. Dieses Verhalten kann mit den Python-Optionen -Wd oder -Wa überschrieben werden (siehe Warnungssteuerung) und warnings auf None belassen.

Geändert in Version 3.2: Der Parameter warnings wurde hinzugefügt.

Geändert in Version 3.2: Der Standard-Stream wird zur Instanziierungszeit auf sys.stderr gesetzt, anstatt zur Importzeit.

Geändert in Version 3.5: Der Parameter tb_locals wurde hinzugefügt.

Geändert in Version 3.12: Der Parameter durations wurde hinzugefügt.

_makeResult()¶

Diese Methode gibt die Instanz von TestResult zurück, die von run() verwendet wird. Sie ist nicht dafür bestimmt, direkt aufgerufen zu werden, kann aber in Unterklassen überschrieben werden, um ein benutzerdefiniertes TestResult bereitzustellen.

_makeResult() instanziiert die Klasse oder aufrufbare Funktion, die im Konstruktor von TextTestRunner als Argument resultclass übergeben wird. Standardmäßig ist dies TextTestResult, wenn keine resultclass angegeben ist. Die Ergebnisklasse wird mit den folgenden Argumenten instanziiert

stream, descriptions, verbosity

run(test)¶: Diese Methode ist die Hauptschnittstelle für TextTestRunner. Diese Methode nimmt eine Instanz von TestSuite oder TestCase entgegen. Ein TestResult wird durch Aufruf von _makeResult() erstellt, und die Tests werden ausgeführt und die Ergebnisse auf stdout gedruckt.

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)¶

Ein Kommandozeilenprogramm, das eine Reihe von Tests aus module lädt und ausführt; dies dient hauptsächlich dazu, Testmodule bequem ausführbar zu machen. Die einfachste Verwendung dieser Funktion ist, die folgende Zeile am Ende eines Testskripts einzufügen

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

Sie können Tests mit detaillierteren Informationen ausführen, indem Sie das Argument verbosity übergeben

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

Das Argument defaultTest ist entweder der Name eines einzelnen Tests oder eine Iterable von Testnamen, die ausgeführt werden sollen, wenn über argv keine Testnamen angegeben sind. Wenn es nicht angegeben oder None ist und keine Testnamen über argv bereitgestellt werden, werden alle in module gefundenen Tests ausgeführt.

Das Argument argv kann eine Liste von Optionen sein, die an das Programm übergeben werden, wobei das erste Element der Programmname ist. Wenn es nicht angegeben oder None ist, werden die Werte von sys.argv verwendet.

Das Argument testRunner kann entweder eine Test-Runner-Klasse oder eine bereits erstellte Instanz davon sein. Standardmäßig ruft main sys.exit() mit einem Exit-Code auf, der den Erfolg (0) oder Misserfolg (1) der ausgeführten Tests angibt. Ein Exit-Code von 5 bedeutet, dass keine Tests ausgeführt oder übersprungen wurden.

Das Argument testLoader muss eine Instanz von TestLoader sein und ist standardmäßig defaultTestLoader.

main unterstützt die Verwendung mit dem interaktiven Interpreter, indem das Argument exit=False übergeben wird. Dies zeigt das Ergebnis auf der Standardausgabe an, ohne sys.exit() aufzurufen

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

Die Parameter failfast, catchbreak und buffer haben die gleiche Auswirkung wie die gleichnamigen Kommandozeilenoptionen.

Das Argument warnings gibt den Warnungsfilter an, der beim Ausführen der Tests verwendet werden soll. Wenn es nicht angegeben ist, bleibt es None, wenn eine -W Option an python übergeben wird (siehe Warnungssteuerung), andernfalls wird es auf 'default' gesetzt.

Der Aufruf von main gibt ein Objekt mit dem Attribut result zurück, das das Ergebnis der ausgeführten Tests als unittest.TestResult enthält.

Geändert in Version 3.1: Der Parameter exit wurde hinzugefügt.

Geändert in Version 3.2: Die Parameter verbosity, failfast, catchbreak, buffer und warnings wurden hinzugefügt.

Geändert in Version 3.4: Der Parameter defaultTest wurde so geändert, dass er auch eine Iterable von Testnamen akzeptiert.

load_tests Protokoll¶

Hinzugefügt in Version 3.2.

Module oder Pakete können anpassen, wie Tests von ihnen während normaler Testläufe oder Testentdeckung geladen werden, indem sie eine Funktion namens load_tests implementieren.

Wenn ein Testmodul load_tests definiert, wird es von TestLoader.loadTestsFromModule() mit den folgenden Argumenten aufgerufen

load_tests(loader, standard_tests, pattern)

wobei pattern direkt von loadTestsFromModule weitergegeben wird. Es ist standardmäßig None.

Es sollte eine TestSuite zurückgegeben werden.

loader ist die Instanz von TestLoader, die das Laden durchführt. standard_tests sind die Tests, die standardmäßig aus dem Modul geladen würden. Es ist üblich, dass Testmodule nur Tests aus dem Standardsatz von Tests hinzufügen oder entfernen möchten. Das dritte Argument wird beim Laden von Paketen als Teil der Testentdeckung verwendet.

Eine typische load_tests Funktion, die Tests aus einem bestimmten Satz von TestCase-Klassen lädt, könnte so aussehen

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

Wenn die Entdeckung in einem Verzeichnis mit einer Paketstruktur gestartet wird, entweder über die Kommandozeile oder durch Aufruf von TestLoader.discover(), dann wird die __init__.py Datei des Pakets auf load_tests geprüft. Wenn diese Funktion nicht existiert, wird die Entdeckung in das Paket rekursiv fortgesetzt, als wäre es nur ein weiteres Verzeichnis. Andernfalls wird die Entdeckung der Tests des Pakets load_tests überlassen, die mit den folgenden Argumenten aufgerufen wird

load_tests(loader, standard_tests, pattern)

Dies sollte eine TestSuite zurückgeben, die alle Tests aus dem Paket repräsentiert. (standard_tests enthält nur Tests, die aus __init__.py gesammelt wurden.)

Da das Muster an load_tests übergeben wird, ist das Paket frei, die Testentdeckung fortzusetzen (und potenziell zu modifizieren). Eine load_tests Funktion, die nichts tut, für ein Testpaket würde so aussehen

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

Geändert in Version 3.5: Die Entdeckung prüft Paketnamen nicht mehr auf Übereinstimmung mit dem pattern, da Paketnamen nicht mit dem Standardmuster übereinstimmen können.

Klassen- und Modul-Fixtures¶

Klassen- und Modul-Level-Fixtures werden in TestSuite implementiert. Wenn die Test-Suite auf einen Test aus einer neuen Klasse trifft, wird die tearDownClass() der vorherigen Klasse (falls vorhanden) aufgerufen, gefolgt von setUpClass() der neuen Klasse.

Ähnlich, wenn ein Test aus einem anderen Modul als der vorherige Test stammt, wird tearDownModule aus dem vorherigen Modul ausgeführt, gefolgt von setUpModule aus dem neuen Modul.

Nachdem alle Tests ausgeführt wurden, werden die abschließenden tearDownClass und tearDownModule aufgerufen.

Beachten Sie, dass gemeinsame Fixtures nicht gut mit [potenziellen] Funktionen wie Testparallelisierung harmonieren und die Testisolation brechen. Sie sollten mit Vorsicht verwendet werden.

Die Standardreihenfolge der Tests, die von den unittest-Testladern erstellt werden, ist, alle Tests aus denselben Modulen und Klassen zusammenzufassen. Dies führt dazu, dass setUpClass / setUpModule (usw.) genau einmal pro Klasse und Modul aufgerufen werden. Wenn Sie die Reihenfolge zufällig ändern, so dass Tests aus verschiedenen Modulen und Klassen nebeneinander liegen, können diese gemeinsamen Fixture-Funktionen während eines Testlaufs mehrmals aufgerufen werden.

Gemeinsame Fixtures sind nicht für Suiten mit nicht standardmäßiger Reihenfolge vorgesehen. Eine BaseTestSuite existiert weiterhin für Frameworks, die keine Unterstützung für gemeinsame Fixtures wünschen.

Wenn während einer der gemeinsamen Fixture-Funktionen Ausnahmen ausgelöst werden, wird der Test als Fehler gemeldet. Da es keine entsprechende Testinstanz gibt, wird ein _ErrorHolder-Objekt (das die gleiche Schnittstelle wie ein TestCase hat) erstellt, um den Fehler darzustellen. Wenn Sie nur den Standard-unittest-Test-Runner verwenden, ist dieses Detail unerheblich, aber wenn Sie ein Framework-Autor sind, kann es relevant sein.

setUpClass und tearDownClass¶

Diese müssen als Klassenmethoden implementiert werden

import unittest

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

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

Wenn Sie möchten, dass die setUpClass und tearDownClass von Basisklassen aufgerufen werden, müssen Sie sie selbst aufrufen. Die Implementierungen in TestCase sind leer.

Wenn während eines setUpClass eine Ausnahme ausgelöst wird, werden die Tests in der Klasse nicht ausgeführt und tearDownClass nicht ausgeführt. Übersprungene Klassen haben weder setUpClass noch tearDownClass ausgeführt. Wenn die Ausnahme eine SkipTest-Ausnahme ist, wird die Klasse als übersprungen statt als Fehler gemeldet.

setUpModule und tearDownModule¶

Diese sollten als Funktionen implementiert werden

def setUpModule():
    createConnection()

def tearDownModule():
    closeConnection()

Wenn in einem setUpModule eine Ausnahme ausgelöst wird, werden keine Tests im Modul ausgeführt und tearDownModule wird nicht ausgeführt. Wenn die Ausnahme eine SkipTest-Ausnahme ist, wird das Modul als übersprungen statt als Fehler gemeldet.

Um Aufräumcode hinzuzufügen, der auch im Falle einer Ausnahme ausgeführt werden muss, verwenden Sie addModuleCleanup

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

Fügt eine Funktion hinzu, die nach tearDownModule() aufgerufen wird, um Ressourcen aufzuräumen, die während der Testklasse verwendet wurden. Funktionen werden in umgekehrter Reihenfolge ihrer Hinzufügung aufgerufen (letzter Ein, erster Aus - LIFO). Sie werden mit den Argumenten und Schlüsselwortargumenten aufgerufen, die an addModuleCleanup() übergeben wurden, als sie hinzugefügt wurden.

Wenn setUpModule() fehlschlägt, d. h. tearDownModule() nicht aufgerufen wird, werden die hinzugefügten Bereinigungsfunktionen trotzdem aufgerufen.

Hinzugefügt in Version 3.8.

unittest.enterModuleContext(cm)¶: Betritt den bereitgestellten Kontextmanager. Wenn dies erfolgreich ist, wird auch seine Methode __exit__() als Bereinigungsfunktion durch addModuleCleanup() hinzugefügt und das Ergebnis der Methode __enter__() zurückgegeben.

Hinzugefügt in Version 3.11.

unittest.doModuleCleanups()¶

Diese Funktion wird bedingungslos nach tearDownModule() aufgerufen, oder nach setUpModule(), wenn setUpModule() eine Ausnahme auslöst.

Sie ist dafür verantwortlich, alle Bereinigungsfunktionen aufzurufen, die von addModuleCleanup() hinzugefügt wurden. Wenn Sie möchten, dass Bereinigungsfunktionen *vor* tearDownModule() aufgerufen werden, können Sie doModuleCleanups() selbst aufrufen.

doModuleCleanups() entfernt Methoden vom Stapel der Bereinigungsfunktionen nacheinander, sodass sie jederzeit aufgerufen werden kann.

Hinzugefügt in Version 3.8.

Signalbehandlung¶

Hinzugefügt in Version 3.2.

Die Kommandozeilenoption -c/--catch für unittest zusammen mit dem Parameter catchbreak für unittest.main() sorgen für eine benutzerfreundlichere Behandlung von Strg+C während eines Testlaufs. Mit aktivierter Strg+C-Verhalten wird der aktuell laufende Test abgeschlossen, der Testlauf wird dann beendet und alle bisherigen Ergebnisse gemeldet. Ein zweites Strg+C löst wie üblich eine KeyboardInterrupt aus.

Der Signalhandler für die Strg+C-Behandlung versucht, mit Code oder Tests kompatibel zu bleiben, die ihren eigenen signal.SIGINT-Handler installieren. Wenn der unittest-Handler aufgerufen wird, aber *nicht* der installierte signal.SIGINT-Handler ist, d. h. er wurde vom System unter Test ersetzt und delegiert, ruft er den Standardhandler auf. Dies ist normalerweise das erwartete Verhalten von Code, der einen installierten Handler ersetzt und an ihn delegiert. Für einzelne Tests, bei denen die Strg+C-Behandlung von unittest deaktiviert werden muss, kann der Dekorator removeHandler() verwendet werden.

Es gibt einige Hilfsfunktionen für Framework-Autoren, um die Strg+C-Behandlungsfunktionalität innerhalb von Test-Frameworks zu ermöglichen.

unittest.installHandler()¶: Installiert den Strg+C-Handler. Wenn ein signal.SIGINT empfangen wird (normalerweise als Reaktion auf die Eingabe von Strg+C durch den Benutzer), wird für alle registrierten Ergebnisse stop() aufgerufen.

unittest.registerResult(result)¶

Registriert ein TestResult-Objekt für die Strg+C-Behandlung. Das Registrieren eines Ergebnisses speichert eine schwache Referenz darauf, sodass es die Garbage Collection des Ergebnisses nicht verhindert.

Das Registrieren eines TestResult-Objekts hat keine Nebenwirkungen, wenn die Strg+C-Behandlung nicht aktiviert ist. Test-Frameworks können also alle von ihnen erstellten Ergebnisse bedingungslos registrieren, unabhängig davon, ob die Behandlung aktiviert ist oder nicht.

unittest.removeResult(result)¶: Entfernt ein registriertes Ergebnis. Sobald ein Ergebnis entfernt wurde, wird stop() für dieses Ergebnisobjekt aufgrund eines Strg+C nicht mehr aufgerufen.

unittest.removeHandler(function=None)¶

Wenn diese Funktion ohne Argumente aufgerufen wird, entfernt sie den Strg+C-Handler, falls er installiert wurde. Diese Funktion kann auch als Test-Dekorator verwendet werden, um den Handler während der Ausführung des Tests vorübergehend zu entfernen

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

`unittest` — Unit testing framework¶

Einfaches Beispiel¶

Befehlszeilenschnittstelle¶

Kommandozeilenoptionen¶

Test-Discovery¶

Organisation des Testcodes¶

Wiederverwendung von altem Testcode¶

Tests überspringen und erwartete Fehler¶

Unterscheiden von Testiterationen mithilfe von Subtests¶

Klassen und Funktionen¶

Testfälle¶

Tests gruppieren¶

Tests laden und ausführen¶

load_tests Protokoll¶

Klassen- und Modul-Fixtures¶

setUpClass und tearDownClass¶

setUpModule und tearDownModule¶

Signalbehandlung¶

Inhaltsverzeichnis

Vorheriges Thema

Nächstes Thema

Diese Seite

unittest — Unit testing framework¶

Einfaches Beispiel¶

Befehlszeilenschnittstelle¶

Kommandozeilenoptionen¶

Test-Discovery¶

Organisation des Testcodes¶

Wiederverwendung von altem Testcode¶

Tests überspringen und erwartete Fehler¶

Unterscheiden von Testiterationen mithilfe von Subtests¶

Klassen und Funktionen¶

Testfälle¶

Tests gruppieren¶

Tests laden und ausführen¶

load_tests Protokoll¶

Klassen- und Modul-Fixtures¶

setUpClass und tearDownClass¶

setUpModule und tearDownModule¶

Signalbehandlung¶

`unittest` — Unit testing framework¶