API-Referenz

Diese Seite enthält die vollständige Referenz zur API von pytest.

Konstanten

pytest.__version__

Die aktuelle pytest-Version als String

>>> import pytest
>>> pytest.__version__
'7.0.0'

pytest.HIDDEN_PARAM

Hinzugefügt in Version 8.4.

Kann an ids von Metafunc.parametrize oder an id von pytest.param() übergeben werden, um einen Parametersatz aus dem Testnamen zu verbergen. Kann höchstens 1 Mal verwendet werden, da Testnamen eindeutig sein müssen.

pytest.version_tuple

Hinzugefügt in Version 7.0.

Die aktuelle pytest-Version als Tupel

>>> import pytest
>>> pytest.version_tuple
(7, 0, 0)

Bei Vorabversionen ist die letzte Komponente ein String mit der Vorabversionsnummer

>>> import pytest
>>> pytest.version_tuple
(7, 0, '0rc1')

Funktionen

pytest.approx

approx(expected, rel=None, abs=None, nan_ok=False)

Prüft, ob zwei Zahlen (oder zwei geordnete Zahlenfolgen) bis auf eine bestimmte Toleranz gleich sind.

Aufgrund der Gleitkomma-Arithmetik: Probleme und Einschränkungen sind Zahlen, die wir intuitiv als gleich erwarten würden, nicht immer gleich.

>>> 0.1 + 0.2 == 0.3
False

Dieses Problem tritt häufig beim Schreiben von Tests auf, z. B. wenn sichergestellt werden soll, dass Gleitkommazahlen die erwarteten Werte haben. Eine Möglichkeit, dieses Problem zu lösen, besteht darin, zu prüfen, ob zwei Gleitkommazahlen innerhalb einer bestimmten Toleranz gleich sind.

>>> abs((0.1 + 0.2) - 0.3) < 1e-6
True

Vergleiche wie dieser sind jedoch mühsam zu schreiben und schwer zu verstehen. Außerdem werden absolute Vergleiche wie der obige normalerweise nicht empfohlen, da es keine Toleranz gibt, die für alle Situationen gut funktioniert. 1e-6 ist gut für Zahlen um 1, aber zu klein für sehr große Zahlen und zu groß für sehr kleine. Es ist besser, die Toleranz als Bruchteil des erwarteten Werts auszudrücken, aber relative Vergleiche dieser Art sind noch schwieriger korrekt und prägnant zu schreiben.

Die Klasse approx führt Gleitkommavergleiche mit einer möglichst intuitiven Syntax durch.

>>> from pytest import approx
>>> 0.1 + 0.2 == approx(0.3)
True

Die gleiche Syntax funktioniert auch für geordnete Zahlenfolgen.

>>> (0.1 + 0.2, 0.2 + 0.4) == approx((0.3, 0.6))
True

numpy-Arrays

>>> import numpy as np
>>> np.array([0.1, 0.2]) + np.array([0.2, 0.4]) == approx(np.array([0.3, 0.6]))
True

Und für ein numpy-Array gegen einen Skalar.

>>> import numpy as np
>>> np.array([0.1, 0.2]) + np.array([0.2, 0.1]) == approx(0.3)
True

Es werden nur geordnete Sequenzen unterstützt, da approx die relative Position der Sequenzen eindeutig ermitteln muss. Das bedeutet, dass sets und andere ungeordnete Sequenzen nicht unterstützt werden.

Schließlich können auch Wörterbuchwerte verglichen werden.

>>> {'a': 0.1 + 0.2, 'b': 0.2 + 0.4} == approx({'a': 0.3, 'b': 0.6})
True

Der Vergleich ist wahr, wenn beide Abbildungen dieselben Schlüssel haben und ihre jeweiligen Werte den erwarteten Toleranzen entsprechen.

Toleranzen

Standardmäßig betrachtet approx Zahlen innerhalb einer relativen Toleranz von 1e-6 (d. h. ein Millionstel) ihres erwarteten Werts als gleich. Diese Behandlung würde zu überraschenden Ergebnissen führen, wenn der erwartete Wert 0.0 wäre, da nichts außer 0.0 selbst relativ nahe an 0.0 liegt. Um diesen Fall weniger überraschend zu handhaben, betrachtet approx auch Zahlen innerhalb einer absoluten Toleranz von 1e-12 ihres erwarteten Werts als gleich. Unendlich und NaN sind Sonderfälle. Unendlich wird unabhängig von der relativen Toleranz nur mit sich selbst als gleich betrachtet. NaN wird standardmäßig nicht als gleich zu irgendetwas betrachtet, aber Sie können es mit sich selbst als gleich behandeln, indem Sie das Argument nan_ok auf True setzen. (Dies soll den Vergleich von Arrays erleichtern, die NaN als "keine Daten" verwenden.)

Sowohl die relative als auch die absolute Toleranz können durch Übergabe von Argumenten an den approx-Konstruktor geändert werden.

>>> 1.0001 == approx(1)
False
>>> 1.0001 == approx(1, rel=1e-3)
True
>>> 1.0001 == approx(1, abs=1e-3)
True

Wenn Sie abs angeben, aber nicht rel, wird der Vergleich die relative Toleranz überhaupt nicht berücksichtigen. Mit anderen Worten, zwei Zahlen, die innerhalb der Standard-Relativtoleranz von 1e-6 liegen, werden immer noch als ungleich betrachtet, wenn sie die angegebene absolute Toleranz überschreiten. Wenn Sie sowohl abs als auch rel angeben, werden die Zahlen als gleich betrachtet, wenn eine der beiden Toleranzen erfüllt ist.

>>> 1 + 1e-8 == approx(1)
True
>>> 1 + 1e-8 == approx(1, abs=1e-12)
False
>>> 1 + 1e-8 == approx(1, rel=1e-6, abs=1e-12)
True

Nicht-numerische Typen

Sie können approx auch zum Vergleichen von nicht-numerischen Typen oder Dictionaries und Sequenzen, die nicht-numerische Typen enthalten, verwenden. In diesem Fall wird auf strikte Gleichheit zurückgegriffen. Dies kann nützlich sein, um Dictionaries und Sequenzen zu vergleichen, die optionale Werte enthalten können.

>>> {"required": 1.0000005, "optional": None} == approx({"required": 1, "optional": None})
True
>>> [None, 1.0000005] == approx([None,1])
True
>>> ["foo", 1.0000005] == approx([None,1])
False

Wenn Sie darüber nachdenken, approx zu verwenden, möchten Sie vielleicht wissen, wie es sich im Vergleich zu anderen guten Methoden zum Vergleichen von Gleitkommazahlen verhält. All diese Algorithmen basieren auf relativen und absoluten Toleranzen und sollten größtenteils übereinstimmen, aber sie weisen sinnvolle Unterschiede auf.

• math.isclose(a, b, rel_tol=1e-9, abs_tol=0.0): True, wenn die relative Toleranz in Bezug auf a oder b erfüllt ist oder wenn die absolute Toleranz erfüllt ist. Da die relative Toleranz in Bezug auf beide a und b berechnet wird, ist dieser Test symmetrisch (d. h., weder a noch b ist ein "Referenzwert"). Sie müssen eine absolute Toleranz angeben, wenn Sie mit 0.0 vergleichen möchten, da standardmäßig keine Toleranz vorhanden ist. Weitere Informationen: math.isclose().

• numpy.isclose(a, b, rtol=1e-5, atol=1e-8): True, wenn der Unterschied zwischen a und b kleiner ist als die Summe der relativen Toleranz in Bezug auf b und der absoluten Toleranz. Da die relative Toleranz nur in Bezug auf b berechnet wird, ist dieser Test asymmetrisch und Sie können b als Referenzwert betrachten. Die Unterstützung für den Vergleich von Sequenzen wird durch numpy.allclose() bereitgestellt. Weitere Informationen: numpy.isclose.

• unittest.TestCase.assertAlmostEqual(a, b): True, wenn a und b innerhalb einer absoluten Toleranz von 1e-7 liegen. Es wird keine relative Toleranz berücksichtigt, daher ist diese Funktion für sehr große oder sehr kleine Zahlen nicht geeignet. Außerdem ist sie nur in Unterklassen von unittest.TestCase verfügbar und ist unschön, da sie nicht PEP8 folgt. Weitere Informationen: unittest.TestCase.assertAlmostEqual().

• a == pytest.approx(b, rel=1e-6, abs=1e-12): True, wenn die relative Toleranz in Bezug auf b erfüllt ist oder wenn die absolute Toleranz erfüllt ist. Da die relative Toleranz nur in Bezug auf b berechnet wird, ist dieser Test asymmetrisch und Sie können b als Referenzwert betrachten. Im Sonderfall, dass Sie explizit eine absolute Toleranz, aber keine relative Toleranz angeben, wird nur die absolute Toleranz berücksichtigt.

Hinweis

approx kann numpy-Arrays verarbeiten, aber wir empfehlen die spezialisierten Testhelfer in Testunterstützung, wenn Sie Unterstützung für Vergleiche, NaNs oder ULP-basierte Toleranzen benötigen.

Um Strings mit Regex abzugleichen, können Sie Matches aus dem re_assert-Paket verwenden.

Hinweis

Im Gegensatz zur eingebauten Gleichheit betrachtet diese Funktion Booleans als ungleich zu numerischem Null oder Eins. Zum Beispiel

>>> 1 == approx(True)
False

Warnung

Geändert in Version 3.2.

Um inkonsistentes Verhalten zu vermeiden, wird für Vergleiche mit >, >=, < und <= ein TypeError ausgelöst. Das folgende Beispiel verdeutlicht das Problem.

assert approx(0.1) > 0.1 + 1e-10  # calls approx(0.1).__gt__(0.1 + 1e-10)
assert 0.1 + 1e-10 > approx(0.1)  # calls approx(0.1).__lt__(0.1 + 1e-10)

Im zweiten Beispiel erwartet man, dass approx(0.1).__le__(0.1 + 1e-10) aufgerufen wird. Stattdessen wird approx(0.1).__lt__(0.1 + 1e-10) für den Vergleich verwendet. Dies liegt daran, dass die Aufrufhierarchie von Rich Comparisons einem festen Verhalten folgt. Weitere Informationen: object.__ge__().

Geändert in Version 3.7.1: approx löst einen TypeError aus, wenn es auf einen Dictionary-Wert oder ein Sequenzelement vom nicht-numerischen Typ stößt.

Geändert in Version 6.1.0: approx greift für nicht-numerische Typen auf strikte Gleichheit zurück, anstatt TypeError auszulösen.

pytest.fail

Tutorial: Wie man skip und xfail verwendet, um mit Tests umzugehen, die nicht erfolgreich sein können

fail(reason[, pytrace=True])

Schlägt einen ausführenden Test explizit mit der angegebenen Meldung fehl.

Parameter:

• reason (str) – Die Meldung, die dem Benutzer als Grund für den Fehler angezeigt wird.

• pytrace (bool) – Wenn False, stellt msg die vollständigen Fehlerinformationen dar und es wird kein Python-Traceback ausgegeben.

Löst aus:

pytest.fail.Exception – Die ausgelöste Ausnahme.

class pytest.fail.Exception

Die von pytest.fail() ausgelöste Ausnahme.

pytest.skip

skip(reason[, allow_module_level=False])

Überspringt einen ausführenden Test mit der angegebenen Meldung.

Diese Funktion sollte nur während des Testens (Setup, Aufruf oder Teardown) oder während der Sammlung unter Verwendung des Flags allow_module_level aufgerufen werden. Diese Funktion kann auch in Doctests aufgerufen werden.

Parameter:

• reason (str) – Die Meldung, die dem Benutzer als Grund für das Überspringen angezeigt wird.

• allow_module_level (bool) –

  Ermöglicht den Aufruf dieser Funktion auf Modulebene. Das Auslösen der Skip-Ausnahme auf Modulebene stoppt die Ausführung des Moduls und verhindert die Sammlung aller Tests im Modul, auch derjenigen, die vor dem skip-Aufruf definiert wurden.

  Standardmäßig False.

Löst aus:

pytest.skip.Exception – Die ausgelöste Ausnahme.

Hinweis

Es ist besser, den Marker pytest.mark.skipif zu verwenden, wenn möglich, um einen Test unter bestimmten Bedingungen wie nicht übereinstimmenden Plattformen oder Abhängigkeiten zu überspringen. Verwenden Sie similarly die Direktive # doctest: +SKIP (siehe doctest.SKIP), um einen Doctest statisch zu überspringen.

class pytest.skip.Exception

Die von pytest.skip() ausgelöste Ausnahme.

pytest.importorskip

importorskip(modname, minversion=None, reason=None, *, exc_type=None)

Importiert und gibt das angeforderte Modul modname zurück, oder überspringt den aktuellen Test, wenn das Modul nicht importiert werden kann.

Parameter:

• modname (str) – Der Name des zu importierenden Moduls.

• minversion (str | None) – Wenn angegeben, muss das Attribut __version__ des importierten Moduls mindestens diese Mindestversion haben, andernfalls wird der Test trotzdem übersprungen.

• reason (str | None) – Wenn angegeben, wird dieser Grund als Meldung angezeigt, wenn das Modul nicht importiert werden kann.

• exc_type (type[ImportError] | None) –

  Die Ausnahme, die abgefangen werden sollte, um Module zu überspringen. Muss ImportError oder eine Unterklasse sein.

  Wenn das Modul importiert werden kann, aber einen ImportError auslöst, gibt pytest eine Warnung an den Benutzer aus, da Benutzer oft erwarten, dass das Modul nicht gefunden wird (was stattdessen ModuleNotFoundError auslösen würde).

  Diese Warnung kann durch explizites Übergeben von exc_type=ImportError unterdrückt werden.

  Siehe Standardverhalten von pytest.importorskip bezüglich ImportError für Details.

Gibt zurück:

Das importierte Modul. Dies sollte seinem kanonischen Namen zugewiesen werden.

Löst aus:

pytest.skip.Exception – Wenn das Modul nicht importiert werden kann.

Rückgabetyp:

Any

Beispiel

docutils = pytest.importorskip("docutils")

Hinzugefügt in Version 8.2: Der Parameter exc_type.

pytest.xfail

xfail(reason='')

Schlägt einen ausführenden Test oder eine Setup-Funktion imperativ mit der angegebenen Begründung fehl.

Diese Funktion sollte nur während des Testens (Setup, Aufruf oder Teardown) aufgerufen werden.

Kein anderer Code wird nach der Verwendung von xfail() ausgeführt (sie wird intern durch Auslösen einer Ausnahme implementiert).

Parameter:

reason (str) – Die Meldung, die dem Benutzer als Grund für das xfail angezeigt wird.

Hinweis

Es ist besser, den Marker pytest.mark.xfail zu verwenden, wenn möglich, um einen Test unter bestimmten Bedingungen wie bekannten Fehlern oder fehlenden Funktionen als xfail zu deklarieren.

Löst aus:

pytest.xfail.Exception – Die ausgelöste Ausnahme.

class pytest.xfail.Exception

Die von pytest.xfail() ausgelöste Ausnahme.

pytest.exit

exit(reason[, returncode=None])

Beendet den Testprozess.

Parameter:

• reason (str) – Die Meldung, die als Grund für das Beenden von pytest angezeigt wird. reason hat nur einen Standardwert, da msg veraltet ist.

• returncode (int | None) – Rückgabecode, der beim Beenden von pytest verwendet werden soll. None bedeutet dasselbe wie 0 (kein Fehler), dasselbe wie bei sys.exit().

Löst aus:

pytest.exit.Exception – Die ausgelöste Ausnahme.

class pytest.exit.Exception

Die von pytest.exit() ausgelöste Ausnahme.

pytest.main

Tutorial: Aufrufen von pytest aus Python-Code

main(args=None, plugins=None)

Führt einen In-Prozess-Testlauf durch.

Parameter:

• args (list[str] | PathLike[str] | None) – Liste der Befehlszeilenargumente. Wenn None oder nicht angegeben, werden standardmäßig Argumente direkt aus der Befehlszeile des Prozesses gelesen (sys.argv).

• plugins (Sequence[str | object] | None) – Liste der Plugin-Objekte, die während der Initialisierung automatisch registriert werden.

Gibt zurück:

Ein Exit-Code.

Rückgabetyp:

int | ExitCode

pytest.param

param(*values[, id][, marks])

Gibt einen Parameter in pytest.mark.parametrize-Aufrufen oder parametrisierten Fixtures an.

@pytest.mark.parametrize(
    "test_input,expected",
    [
        ("3+5", 8),
        pytest.param("6*9", 42, marks=pytest.mark.xfail),
    ],
)
def test_eval(test_input, expected):
    assert eval(test_input) == expected

Parameter:

• values (object) – Variable Argumente der Werte des Parametersatzes, in Ordnung.

• marks (MarkDecorator | Collection[MarkDecorator | Mark]) –

  Eine einzelne Markierung oder eine Liste von Markierungen, die auf diesen Parametersatz angewendet werden sollen.

  pytest.mark.usefixtures kann nicht über diesen Parameter hinzugefügt werden.

• id (str | Literal[pytest.HIDDEN_PARAM] | None) –

  Die ID, die diesem Parametersatz zugeordnet werden soll.

  Hinzugefügt in Version 8.4: pytest.HIDDEN_PARAM bedeutet, den Parametersatz aus dem Testnamen zu verbergen. Kann höchstens 1 Mal verwendet werden, da Testnamen eindeutig sein müssen.

pytest.raises

Tutorial: Assertions über ungefähre Gleichheit

with raises(expected_exception: type[E] | tuple[type[E], ...], *, match: str | Pattern[str] | None = ..., check: Callable[[E], bool] = ...) → RaisesExc[E] as excinfo

with raises(*, match: str | Pattern[str], check: Callable[[BaseException], bool] = ...) → RaisesExc[BaseException] as excinfo

with raises(*, check: Callable[[BaseException], bool]) → RaisesExc[BaseException] as excinfo

mit raises(expected_exception: type[E] | tuple[type[E], ...], func: Callable[..., Any], *args: Any, **kwargs: Any) → ExceptionInfo[E] als excinfo

Assertet, dass ein Codeblock/Funktionsaufruf eine Ausnahme auslöst, oder eine ihrer Unterklassen.

Parameter:

• expected_exception –

  Der erwartete Ausnahmetyp oder ein Tupel, wenn eine von mehreren möglichen Ausnahmetypen erwartet wird. Beachten Sie, dass auch Unterklassen der übergebenen Ausnahmen übereinstimmen.

  Dies ist kein erforderlicher Parameter. Sie können auch nur match und/oder check verwenden, um die ausgelöste Ausnahme zu überprüfen.

• match (str | re.Pattern[str] | None) –

  Wenn angegeben, ein String, der einen regulären Ausdruck enthält, oder ein regulärer Ausdrucksobjekt, das gegen die String-Darstellung der Ausnahme und ihre PEP 678 __notes__ mittels re.search() getestet wird.

  Um einen literalen String abzugleichen, der Sonderzeichen enthalten kann, kann das Muster zuerst mit re.escape() escaped werden.

  (Dies wird nur verwendet, wenn pytest.raises als Context Manager verwendet wird, und wird ansonsten an die Funktion weitergegeben. Bei Verwendung von pytest.raises als Funktion können Sie verwenden: pytest.raises(Exc, func, match="bestanden bei").match("mein muster").)

• check (Callable[[BaseException], bool]) –

  Hinzugefügt in Version 8.4.

  Wenn angegeben, ein aufrufbares Objekt, das nach der Überprüfung des Typs und des Match-Regex, falls angegeben, mit der Ausnahme als Parameter aufgerufen wird. Wenn es True zurückgibt, wird es als Übereinstimmung betrachtet, andernfalls als fehlgeschlagene Übereinstimmung.

Verwenden Sie pytest.raises als Context Manager, der die Ausnahme des angegebenen Typs oder einer seiner Unterklassen abfängt.

>>> import pytest
>>> with pytest.raises(ZeroDivisionError):
...    1/0

Wenn der Codeblock nicht die erwartete Ausnahme (ZeroDivisionError im obigen Beispiel) oder gar keine Ausnahme auslöst, schlägt die Prüfung stattdessen fehl.

Sie können auch das Schlüsselwortargument match verwenden, um zu behaupten, dass die Ausnahme mit einem Text oder Regex übereinstimmt.

>>> with pytest.raises(ValueError, match='must be 0 or None'):
...     raise ValueError("value must be 0 or None")

>>> with pytest.raises(ValueError, match=r'must be \d+$'):
...     raise ValueError("value must be 42")

Das Argument match durchsucht die formatierte Ausnahmezichenfolge, die alle PEP-678 __notes__ enthält.

>>> with pytest.raises(ValueError, match=r"had a note added"):
...     e = ValueError("value must be 42")
...     e.add_note("had a note added")
...     raise e

Das Argument check muss, wenn es angegeben wird, True zurückgeben, wenn es mit der ausgelösten Ausnahme aufgerufen wird, damit die Übereinstimmung erfolgreich ist, andernfalls wird eine AssertionError ausgelöst.

>>> import errno
>>> with pytest.raises(OSError, check=lambda e: e.errno == errno.EACCES):
...     raise OSError(errno.EACCES, "no permission to view")

Der Context Manager erzeugt ein ExceptionInfo Objekt, das zur Untersuchung der Details der abgefangenen Ausnahme verwendet werden kann.

>>> with pytest.raises(ValueError) as exc_info:
...     raise ValueError("value must be 42")
>>> assert exc_info.type is ValueError
>>> assert exc_info.value.args[0] == "value must be 42"

Warnung

Da pytest.raises Unterklassen abgleicht, seien Sie vorsichtig, wenn Sie es verwenden, um Exception so abzugleichen:

# Careful, this will catch ANY exception raised.
with pytest.raises(Exception):
    some_function()

Da Exception die Basisklasse fast aller Ausnahmen ist, kann dies leicht echte Fehler verdecken, bei denen der Benutzer dies erwartet hat, eine bestimmte Ausnahme auszulösen, aber aufgrund eines Fehlers, der während einer Refaktorierung eingeführt wurde, eine andere Ausnahme ausgelöst wird.

Vermeiden Sie die Verwendung von pytest.raises zum Abfangen von Exception, es sei denn, Sie sind sicher, dass Sie wirklich jede ausgelöste Ausnahme abfangen möchten.

Hinweis

Bei der Verwendung von pytest.raises als Context Manager ist zu beachten, dass normale Context Manager-Regeln gelten und die ausgelöste Ausnahme die letzte Zeile im Geltungsbereich des Context Managers sein muss. Codezeilen danach im Geltungsbereich des Context Managers werden nicht ausgeführt. Zum Beispiel:

>>> value = 15
>>> with pytest.raises(ValueError) as exc_info:
...     if value > 10:
...         raise ValueError("value must be <= 10")
...     assert exc_info.type is ValueError  # This will not execute.

Stattdessen muss der folgende Ansatz gewählt werden (beachten Sie den Unterschied im Geltungsbereich):

>>> with pytest.raises(ValueError) as exc_info:
...     if value > 10:
...         raise ValueError("value must be <= 10")
...
>>> assert exc_info.type is ValueError

Erwartung von Ausnahmegruppen

Wenn Ausnahmen erwartet werden, die in BaseExceptionGroup oder ExceptionGroup eingepackt sind, sollten Sie stattdessen pytest.RaisesGroup verwenden.

Verwendung mit pytest.mark.parametrize

Bei der Verwendung von pytest.mark.parametrize ist es möglich, Tests so zu parametrisieren, dass einige Durchläufe eine Ausnahme auslösen und andere nicht.

Weitere Beispiele finden Sie unter Parametrisierung von bedingtem Auslösen.

Siehe auch

Assertions über ungefähre Gleichheit für weitere Beispiele und detaillierte Diskussionen.

Legacy-Form

Es ist möglich, eine aufrufbare Funktion anzugeben, indem ein aufzurufendes Lambda übergeben wird.

>>> raises(ZeroDivisionError, lambda: 1/0)
<ExceptionInfo ...>

oder Sie können eine beliebige aufrufbare Funktion mit Argumenten angeben.

>>> def f(x): return 1/x
...
>>> raises(ZeroDivisionError, f, 0)
<ExceptionInfo ...>
>>> raises(ZeroDivisionError, f, x=0)
<ExceptionInfo ...>

Die obige Form wird vollständig unterstützt, ist aber für neuen Code nicht empfehlenswert, da die Context Manager-Form als lesbarer und weniger fehleranfällig gilt.

Hinweis

Ähnlich wie bei abgefangenen Ausnahmeobjekten in Python kann das explizite Löschen lokaler Referenzen auf zurückgegebene ExceptionInfo Objekte dem Python-Interpreter helfen, seine Garbage Collection zu beschleunigen.

Das Löschen dieser Referenzen unterbricht einen Referenzzyklus (ExceptionInfo –> abgefangene Ausnahme –> Frame-Stack, der die Ausnahme auslöst –> aktueller Frame-Stack –> lokale Variablen –> ExceptionInfo), was dazu führt, dass Python alle Objekte, die aus diesem Zyklus referenziert werden (einschließlich aller lokalen Variablen im aktuellen Frame), bis zum nächsten zyklischen Garbage Collection-Lauf am Leben erhält. Detailliertere Informationen finden Sie in der offiziellen Python-Dokumentation für die try-Anweisung.

pytest.deprecated_call

Tutorial: Sicherstellen, dass Code eine DeprecationWarning auslöst

mit deprecated_call(*, match: str | Pattern[str] | None = ...) → WarningsRecorder

mit deprecated_call(func: Callable[[...], T], *args: Any, **kwargs: Any) → T

Assertet, dass Code eine DeprecationWarning, PendingDeprecationWarning oder FutureWarning erzeugt.

Diese Funktion kann als Context Manager verwendet werden.

>>> import warnings
>>> def api_call_v2():
...     warnings.warn('use v3 of this api', DeprecationWarning)
...     return 200

>>> import pytest
>>> with pytest.deprecated_call():
...    assert api_call_v2() == 200

Sie kann auch durch Übergabe einer Funktion und *args und **kwargs verwendet werden. In diesem Fall wird sichergestellt, dass der Aufruf von func(*args, **kwargs) einen der oben genannten Warnungstypen erzeugt. Der Rückgabewert ist der Rückgabewert der Funktion.

In der Context Manager-Form können Sie das Schlüsselwortargument match verwenden, um zu behaupten, dass die Warnung mit einem Text oder Regex übereinstimmt.

Der Context Manager erzeugt eine Liste von warnings.WarningMessage Objekten, eines für jede ausgelöste Warnung.

pytest.register_assert_rewrite

Tutorial: Assertion Rewriting

register_assert_rewrite(*names)

Registriert einen oder mehrere Modulnamen, die beim Import neu geschrieben werden sollen.

Diese Funktion stellt sicher, dass dieses Modul oder alle Module innerhalb des Pakets ihre assert-Anweisungen neu geschrieben bekommen. Daher sollten Sie sicherstellen, dass Sie dies aufrufen, bevor das Modul tatsächlich importiert wird, normalerweise in Ihrer __init__.py, wenn Sie ein Plugin sind, das ein Paket verwendet.

Parameter:

names (str) – Die zu registrierenden Modulnamen.

pytest.warns

Tutorial: Assertions für Warnungen mit der Funktion warns

mit warns(expected_warning: type[Warning] | tuple[type[Warning], ...] = <class 'Warning'>, *, match: str | ~re.Pattern[str] | None = None) → WarningsChecker

mit warns(expected_warning: type[Warning] | tuple[type[Warning], ...], func: Callable[[...], T], *args: Any, **kwargs: Any) → T

Assertet, dass Code eine bestimmte Warnungsklasse auslöst.

Insbesondere kann der Parameter expected_warning eine Warnungsklasse oder ein Tupel von Warnungsklassen sein, und der Code innerhalb des with Blocks muss mindestens eine Warnung dieser Klasse oder Klassen ausgeben.

Dieser Helfer erzeugt eine Liste von warnings.WarningMessage Objekten, eines für jede ausgegebene Warnung (unabhängig davon, ob es sich um eine expected_warning handelt oder nicht). Seit pytest 8.0 werden nicht übereinstimmende Warnungen beim Schließen des Kontexts erneut ausgegeben.

Diese Funktion kann als Context Manager verwendet werden.

>>> import pytest
>>> with pytest.warns(RuntimeWarning):
...    warnings.warn("my warning", RuntimeWarning)

In der Context Manager-Form können Sie das Schlüsselwortargument match verwenden, um zu behaupten, dass die Warnung mit einem Text oder Regex übereinstimmt.

>>> with pytest.warns(UserWarning, match='must be 0 or None'):
...     warnings.warn("value must be 0 or None", UserWarning)

>>> with pytest.warns(UserWarning, match=r'must be \d+$'):
...     warnings.warn("value must be 42", UserWarning)

>>> with pytest.warns(UserWarning):  # catch re-emitted warning
...     with pytest.warns(UserWarning, match=r'must be \d+$'):
...         warnings.warn("this is not here", UserWarning)
Traceback (most recent call last):
  ...
Failed: DID NOT WARN. No warnings of type ...UserWarning... were emitted...

Verwendung mit pytest.mark.parametrize

Bei der Verwendung von pytest.mark.parametrize ist es möglich, Tests so zu parametrisieren, dass einige Durchläufe eine Warnung auslösen und andere nicht.

Dies könnte auf die gleiche Weise wie bei Ausnahmen erreicht werden. Weitere Beispiele finden Sie unter Parametrisierung von bedingtem Auslösen.

pytest.freeze_includes

Tutorial: Pytest einfrieren

freeze_includes()

Gibt eine Liste von Modulnamen zurück, die von pytest verwendet werden und von cx_freeze enthalten sein sollten.

Markierungen

Markierungen können verwendet werden, um Metadaten auf Testfunktionen (aber nicht auf Fixtures) anzuwenden, auf die dann von Fixtures oder Plugins zugegriffen werden kann.

pytest.mark.filterwarnings

Tutorial: @pytest.mark.filterwarnings

Fügt markierten Testelementen Warnungsfilter hinzu.

pytest.mark.filterwarnings(filter)

Parameter:

filter (str) –

Eine Warnungsspezifikations-Zeichenkette, die sich aus den Inhalten des Tupels (action, message, category, module, lineno) zusammensetzt, wie im Abschnitt Der Warnungsfilter der Python-Dokumentation beschrieben, getrennt durch ":". Optionale Felder können weggelassen werden. Für die Filterung übergebene Modulnamen werden nicht regex-escaped.

Zum Beispiel

@pytest.mark.filterwarnings("ignore:.*usage will be deprecated.*:DeprecationWarning")
def test_foo(): ...

pytest.mark.parametrize

Tutorial: Wie man Fixtures und Testfunktionen parametrisiert

Diese Markierung hat die gleiche Signatur wie pytest.Metafunc.parametrize(); siehe dort.

pytest.mark.skip

Tutorial: Testfunktionen überspringen

Überspringt bedingungslos eine Testfunktion.

pytest.mark.skip(reason=None)

Parameter:

reason (str) – Grund, warum die Testfunktion übersprungen wird.

pytest.mark.skipif

Tutorial: Testfunktionen überspringen

Überspringt eine Testfunktion, wenn eine Bedingung True ist.

pytest.mark.skipif(condition, *, reason=None)

Parameter:

• condition (bool oder str) – True/False, wenn die Bedingung übersprungen werden soll, oder eine Bedingungszeichenkette.

• reason (str) – Grund, warum die Testfunktion übersprungen wird.

pytest.mark.usefixtures

Tutorial: Fixtures in Klassen und Modulen mit usefixtures verwenden

Markiert eine Testfunktion als Verwendung der angegebenen Fixture-Namen.

pytest.mark.usefixtures(*names)

Parameter:

args – Die Namen der zu verwendenden Fixture, als Strings.

Hinweis

Bei der Verwendung von usefixtures in Hooks können Fixtures nur geladen werden, wenn sie auf eine Testfunktion angewendet werden, bevor das Test-Setup stattfindet (z. B. im Hook pytest_collection_modifyitems).

Beachten Sie auch, dass diese Markierung keine Auswirkungen hat, wenn sie auf Fixtures angewendet wird.

pytest.mark.xfail

Tutorial: XFail: Testfunktionen als erwartungsgemäß fehlerhaft markieren

Markiert eine Testfunktion als erwartungsgemäß fehlerhaft.

pytest.mark.xfail(condition=False, *, reason=None, raises=None, run=True, strict=strict_xfail)

Parameter:

• condition (Union[bool, str]) – Bedingung für die Markierung der Testfunktion als xfail (True/False oder eine Bedingungszeichenkette). Wenn es sich um einen bool handelt, müssen Sie auch reason angeben (siehe Bedingungszeichenkette).

• reason (str) – Grund, warum die Testfunktion als xfail markiert ist.

• raises (Type[Exception]) – Erwartete Ausnahmeklasse (oder Tupel von Klassen), die von der Testfunktion ausgelöst werden soll; andere Ausnahmen führen zum Fehlschlagen des Tests. Beachten Sie, dass Unterklassen der übergebenen Klassen ebenfalls zu einer Übereinstimmung führen (ähnlich wie die except-Anweisung funktioniert).

• run (bool) – Ob die Testfunktion tatsächlich ausgeführt werden soll. Wenn False, wird die Funktion immer xfail sein und nicht ausgeführt werden (nützlich, wenn eine Funktion einen Segfault verursacht).

• strict (bool) –

  • Wenn False, wird die Funktion in der Terminalausgabe als xfailed angezeigt, wenn sie fehlschlägt, und als xpass, wenn sie erfolgreich ist. In beiden Fällen führt dies nicht dazu, dass die gesamte Testsuite fehlschlägt. Dies ist besonders nützlich, um flatterhafte Tests zu markieren (Tests, die zufällig fehlschlagen), um sie später zu behandeln.

  • Wenn True, wird die Funktion in der Terminalausgabe als xfailed angezeigt, wenn sie fehlschlägt. Wenn sie jedoch unerwartet erfolgreich ist, wird die Testsuite fehlschlagen. Dies ist besonders nützlich, um Funktionen zu markieren, die immer fehlschlagen und bei denen es eine klare Anzeige geben sollte, wenn sie unerwartet erfolgreich sind (z. B. eine neue Version einer Bibliothek behebt einen bekannten Fehler).

  Standardmäßig strict_xfail, was standardmäßig False ist.

Benutzerdefinierte Markierungen

Markierungen werden dynamisch über das Factory-Objekt pytest.mark erstellt und als Dekorator angewendet.

Zum Beispiel

@pytest.mark.timeout(10, "slow", method="thread")
def test_function(): ...

Erstellt und hängt ein Mark-Objekt an das gesammelte Item an, das dann von Fixtures oder Hooks mit Node.iter_markers abgerufen werden kann. Das mark-Objekt hat die folgenden Attribute

mark.args == (10, "slow")
mark.kwargs == {"method": "thread"}

Beispiel für die Verwendung mehrerer benutzerdefinierter Markierungen

@pytest.mark.timeout(10, "slow", method="thread")
@pytest.mark.slow
def test_function(): ...

Wenn Node.iter_markers oder Node.iter_markers_with_node mit mehreren Markierungen verwendet wird, wird die Markierung, die der Funktion am nächsten liegt, zuerst durchlaufen. Das obige Beispiel führt zu @pytest.mark.slow gefolgt von @pytest.mark.timeout(...).

Fixtures

Tutorial: Referenz zu Fixtures

Fixtures werden von Testfunktionen oder anderen Fixtures angefordert, indem sie als Argumentnamen deklariert werden.

Beispiel für einen Test, der ein Fixture benötigt

def test_output(capsys):
    print("hello")
    out, err = capsys.readouterr()
    assert out == "hello\n"

Beispiel für ein Fixture, das ein anderes Fixture benötigt

@pytest.fixture
def db_session(tmp_path):
    fn = tmp_path / "db.file"
    return connect(fn)

Weitere Details finden Sie in der vollständigen Fixtures-Dokumentation.

@pytest.fixture

@fixture(fixture_function: Callable[[...], object], *, scope: Literal['session', 'package', 'module', 'class', 'function'] | Callable[[str, Config], Literal['session', 'package', 'module', 'class', 'function']] = 'function', params: Iterable[object] | None = None, autouse: bool = False, ids: Sequence[object | None] | Callable[[Any], object | None] | None = None, name: str | None = None) → FixtureFunctionDefinition

@fixture(fixture_function: None = None, *, scope: Literal['session', 'package', 'module', 'class', 'function'] | Callable[[str, Config], Literal['session', 'package', 'module', 'class', 'function']] = 'function', params: Iterable[object] | None = None, autouse: bool = False, ids: Sequence[object | None] | Callable[[Any], object | None] | None = None, name: str | None = None) → FixtureFunctionMarker

Dekorator zum Markieren einer Fixture-Factory-Funktion.

Dieser Dekorator kann mit oder ohne Parameter verwendet werden, um eine Fixture-Funktion zu definieren.

Der Name der Fixture-Funktion kann später referenziert werden, um ihre Ausführung vor dem Ausführen von Tests zu veranlassen: Testmodule oder -klassen können den Marker pytest.mark.usefixtures(fixturename) verwenden.

Testfunktionen können Fixture-Namen direkt als Eingabeargumente verwenden, in diesem Fall wird die von der Fixture-Funktion zurückgegebene Fixture-Instanz injiziert.

Fixtures können ihre Werte an Testfunktionen über return- oder yield-Anweisungen übergeben. Bei Verwendung von yield wird der Codeblock nach der yield-Anweisung unabhängig vom Testergebnis als Aufräumcode ausgeführt und muss genau einmal liefern.

Parameter:

• scope –

  Der Geltungsbereich, für den dieses Fixture geteilt wird; eines von "function" (Standard), "class", "module", "package" oder "session".

  Dieser Parameter kann auch ein aufrufbares Objekt sein, das (fixture_name, config) als Parameter erhält und eine str mit einem der oben genannten Werte zurückgeben muss.

  Weitere Informationen finden Sie unter Dynamischer Geltungsbereich in der Dokumentation.

• params – Eine optionale Liste von Parametern, die zu mehreren Aufrufen der Fixture-Funktion und aller sie verwendenden Tests führen. Der aktuelle Parameter ist unter request.param verfügbar.

• autouse – Wenn True, wird die Fixture-Funktion für alle Tests aktiviert, die sie sehen können. Wenn False (Standard), ist ein expliziter Verweis erforderlich, um das Fixture zu aktivieren.

• ids – Sequenz von IDs, die jeweils den Parametern entsprechen, sodass sie Teil der Test-ID sind. Wenn keine IDs angegeben werden, werden sie automatisch aus den Parametern generiert.

• name – Der Name des Fixtures. Dies ist standardmäßig der Name der dekorierten Funktion. Wenn ein Fixture im selben Modul verwendet wird, in dem es definiert ist, wird der Funktionsname des Fixtures durch das Funktionsargument überschattet, das das Fixture anfordert. Eine Möglichkeit, dies zu lösen, besteht darin, die dekorierte Funktion fixture_<fixturename> zu nennen und dann @pytest.fixture(name='<fixturename>') zu verwenden.

capfd

Tutorial: So erfassen Sie die Ausgabe von stdout/stderr

capfd()

Aktiviert die Texterfassung von Schreibvorgängen an Dateideskriptoren 1 und 2.

Die erfasste Ausgabe steht über Aufrufe der Methode capfd.readouterr() zur Verfügung, die ein benanntes Tupel (out, err) zurückgibt. out und err sind text-Objekte.

Gibt eine Instanz von CaptureFixture[str] zurück.

Beispiel

def test_system_echo(capfd):
    os.system('echo "hello"')
    captured = capfd.readouterr()
    assert captured.out == "hello\n"

capfdbinary

Tutorial: So erfassen Sie die Ausgabe von stdout/stderr

capfdbinary()

Aktiviert die Byte-Erfassung von Schreibvorgängen an Dateideskriptoren 1 und 2.

Die erfasste Ausgabe steht über Aufrufe der Methode capfd.readouterr() zur Verfügung, die ein benanntes Tupel (out, err) zurückgibt. out und err sind byte-Objekte.

Gibt eine Instanz von CaptureFixture[bytes] zurück.

Beispiel

def test_system_echo(capfdbinary):
    os.system('echo "hello"')
    captured = capfdbinary.readouterr()
    assert captured.out == b"hello\n"

caplog

Tutorial: So verwalten Sie Logging

caplog()

Zugriff auf und Steuerung von Log-Erfassung.

Erfasste Protokolle sind über die folgenden Eigenschaften/Methoden verfügbar

* caplog.messages        -> list of format-interpolated log messages
* caplog.text            -> string containing formatted log output
* caplog.records         -> list of logging.LogRecord instances
* caplog.record_tuples   -> list of (logger_name, level, message) tuples
* caplog.clear()         -> clear captured records and formatted log output string

Gibt eine Instanz von pytest.LogCaptureFixture zurück.

final class LogCaptureFixture

Bietet Zugriff und Steuerung der Log-Erfassung.

property handler: LogCaptureHandler

Ruft den von der Fixture verwendeten Logging-Handler ab.

get_records(when)

Ruft die Logging-Records für eine der möglichen Testphasen ab.

Parameter:

when (Literal['setup', 'call', 'teardown']) – Welche Testphase die Records abgerufen werden sollen. Gültige Werte sind: „setup“, „call“ und „teardown“.

Gibt zurück:

Die Liste der erfassten Records im gegebenen Stadium.

Rückgabetyp:

list[LogRecord]

Hinzugefügt in Version 3.4.

property text: str

Der formatierte Protokolltext.

property records: list[LogRecord]

Die Liste der Log-Records.

property record_tuples: list[tuple[str, int, str]]

Eine Liste einer reduzierten Version von Log-Records, die für Vergleiche von Assertionen bestimmt ist.

Das Format des Tupels ist

(logger_name, log_level, message)

property messages: list[str]

Eine Liste von interpolierten Log-Nachrichten.

Im Gegensatz zu 'records', die die Formatzeichenfolge und Parameter für die Interpolation enthalten, sind die Log-Nachrichten in dieser Liste alle interpoliert.

Im Gegensatz zu 'text', das die Ausgabe des Handlers enthält, sind die Log-Nachrichten in dieser Liste ohne Pegel, Zeitstempel usw. verziert, was exakte Vergleiche zuverlässiger macht.

Beachten Sie, dass Traceback- oder Stack-Informationen (aus logging.exception() oder den Argumenten exc_info oder stack_info für die Logging-Funktionen) nicht enthalten sind, da diese vom Formatter im Handler hinzugefügt werden.

Hinzugefügt in Version 3.7.

clear()

Setzt die Liste der Log-Records und den erfassten Log-Text zurück.

set_level(level, logger=None)

Setzt die Schwellenwertstufe eines Loggers für die Dauer eines Tests.

Protokollmeldungen, die weniger schwerwiegend sind als diese Stufe, werden nicht erfasst.

Geändert in Version 3.4: Die Stufen der von dieser Funktion geänderten Logger werden am Ende des Tests auf ihre ursprünglichen Werte zurückgesetzt.

Aktiviert die angeforderte Protokollierungsstufe, falls sie über logging.disable() deaktiviert wurde.

Parameter:

• level (int | str) – Die Stufe.

• logger (str | None) – Der zu aktualisierende Logger. Wenn nicht angegeben, der Root-Logger.

with at_level(level, logger=None)

Kontextmanager, der die Stufe für die Erfassung von Logs festlegt. Nach dem Ende der 'with'-Anweisung wird die Stufe auf ihren ursprünglichen Wert zurückgesetzt.

Aktiviert die angeforderte Protokollierungsstufe, falls sie über logging.disable() deaktiviert wurde.

Parameter:

• level (int | str) – Die Stufe.

• logger (str | None) – Der zu aktualisierende Logger. Wenn nicht angegeben, der Root-Logger.

with filtering(filter_)

Kontextmanager, der dem caplog-Handler temporär den angegebenen Filter hinzufügt und diesen Filter am Ende des Blocks wieder entfernt.

Parameter:

filter – Ein benutzerdefiniertes logging.Filter-Objekt.

Hinzugefügt in Version 7.5.

capsys

Tutorial: So erfassen Sie die Ausgabe von stdout/stderr

capsys()

Aktiviert die Texterfassung von Schreibvorgängen an sys.stdout und sys.stderr.

Die erfasste Ausgabe steht über Aufrufe der Methode capsys.readouterr() zur Verfügung, die ein benanntes Tupel (out, err) zurückgibt. out und err sind text-Objekte.

Gibt eine Instanz von CaptureFixture[str] zurück.

Beispiel

def test_output(capsys):
    print("hello")
    captured = capsys.readouterr()
    assert captured.out == "hello\n"

class CaptureFixture

Objekt, das von den Fixtures capsys, capsysbinary, capfd und capfdbinary zurückgegeben wird.

readouterr()

Liest und gibt die bisher erfasste Ausgabe zurück und setzt den internen Puffer zurück.

Gibt zurück:

Der erfasste Inhalt als benanntes Tupel mit den String-Attributen out und err.

Rückgabetyp:

CaptureResult

with disabled()

Deaktiviert temporär die Erfassung, während Sie sich im with-Block befinden.

capteesys

Tutorial: So erfassen Sie die Ausgabe von stdout/stderr

capteesys()

Ermöglicht die gleichzeitige Texterfassung und die Weiterleitung von Schreibvorgängen an sys.stdout und sys.stderr, wie sie durch --capture= definiert sind.

Die erfasste Ausgabe ist über capteesys.readouterr() Aufrufe verfügbar, die ein (out, err) Namedtuple zurückgeben. out und err sind text Objekte.

Die Ausgabe wird auch durchgeleitet, sodass sie "live" gedruckt, gemeldet oder beides werden kann, wie durch --capture= definiert.

Gibt eine Instanz von CaptureFixture[str] zurück.

Beispiel

def test_output(capteesys):
    print("hello")
    captured = capteesys.readouterr()
    assert captured.out == "hello\n"

capsysbinary

Tutorial: So erfassen Sie die Ausgabe von stdout/stderr

capsysbinary()

Ermöglicht die Erfassung von Bytes, die in sys.stdout und sys.stderr geschrieben werden.

Die erfasste Ausgabe ist über capsysbinary.readouterr() Aufrufe verfügbar, die ein (out, err) Namedtuple zurückgeben. out und err sind bytes Objekte.

Gibt eine Instanz von CaptureFixture[bytes] zurück.

Beispiel

def test_output(capsysbinary):
    print("hello")
    captured = capsysbinary.readouterr()
    assert captured.out == b"hello\n"

config.cache

Tutorial: So führen Sie fehlgeschlagene Tests erneut aus und behalten den Zustand zwischen Testläufen bei

Das Objekt config.cache ermöglicht es anderen Plugins und Fixtures, Werte über Testläufe hinweg zu speichern und abzurufen. Um darauf von Fixtures aus zuzugreifen, fordern Sie pytestconfig in Ihrem Fixture an und erhalten es mit pytestconfig.cache.

Intern verwendet das Cache-Plugin die einfache dumps/loads API des json Standardmoduls.

config.cache ist eine Instanz von pytest.Cache

final class Cache

Instanz des cache Fixtures.

mkdir(name)

Gibt ein Verzeichnispfadobjekt mit dem angegebenen Namen zurück.

Wenn das Verzeichnis noch nicht existiert, wird es erstellt. Sie können es verwenden, um Dateien zu verwalten, z. B. Datenbank-Dumps zwischen Testläufen zu speichern/abzurufen.

Hinzugefügt in Version 7.0.

Parameter:

name (str) – Muss ein String sein, der keinen / Trenner enthält. Stellen Sie sicher, dass der Name Ihre Plugin- oder Anwendungsidentifikatoren enthält, um Konflikte mit anderen Cache-Benutzern zu vermeiden.

get(key, default)

Gibt den gecachten Wert für den angegebenen Schlüssel zurück.

Wenn noch kein Wert gecacht wurde oder der Wert nicht gelesen werden kann, wird der angegebene Standardwert zurückgegeben.

Parameter:

• key (str) – Muss ein durch / getrennter Wert sein. Normalerweise ist der erste Name der Name Ihres Plugins oder Ihrer Anwendung.

• default – Der Wert, der im Falle eines Cache-Misses oder eines ungültigen Cache-Wertes zurückgegeben werden soll.

set(key, value)

Speichert den Wert für den angegebenen Schlüssel.

Parameter:

• key (str) – Muss ein durch / getrennter Wert sein. Normalerweise ist der erste Name der Name Ihres Plugins oder Ihrer Anwendung.

• value (object) – Muss aus einer beliebigen Kombination von grundlegenden Python-Typen bestehen, einschließlich verschachtelter Typen wie Listen von Wörterbüchern.

doctest_namespace

Tutorial: So führen Sie Doctests aus

doctest_namespace()

Fixture, die ein dict zurückgibt, das in den Namespace von Doctests injiziert wird.

Normalerweise wird dieses Fixture in Verbindung mit einem anderen autouse Fixture verwendet.

@pytest.fixture(autouse=True)
def add_np(doctest_namespace):
    doctest_namespace["np"] = numpy

Weitere Details finden Sie unter: ‘doctest_namespace’ Fixture.

monkeypatch

Tutorial: So monkeypatchen/mocken Sie Module und Umgebungen

monkeypatch()

Ein praktisches Fixture zum Monkey-Patching.

Das Fixture stellt diese Methoden zum Modifizieren von Objekten, Dictionaries oder os.environ bereit.

• monkeypatch.setattr(obj, name, value, raising=True)

• monkeypatch.delattr(obj, name, raising=True)

• monkeypatch.setitem(mapping, name, value)

• monkeypatch.delitem(obj, name, raising=True)

• monkeypatch.setenv(name, value, prepend=None)

• monkeypatch.delenv(name, raising=True)

• monkeypatch.syspath_prepend(path)

• monkeypatch.chdir(path)

• monkeypatch.context()

Alle Modifikationen werden rückgängig gemacht, nachdem die anfordernde Testfunktion oder das Fixture beendet wurde. Der Parameter raising bestimmt, ob ein KeyError oder AttributeError ausgelöst wird, wenn die Set-/Löschoperation das angegebene Ziel nicht hat.

Um Modifikationen, die vom Fixture in einem eingeschränkten Geltungsbereich vorgenommen wurden, rückgängig zu machen, verwenden Sie context().

Gibt eine MonkeyPatch Instanz zurück.

final class MonkeyPatch

Hilfsklasse zum praktischen Monkey-Patching von Attributen/Elementen/Umgebungsvariablen/syspath.

Zurückgegeben vom monkeypatch Fixture.

Geändert in Version 6.2: Kann jetzt auch direkt als pytest.MonkeyPatch() verwendet werden, wenn das Fixture nicht verfügbar ist. In diesem Fall verwenden Sie with MonkeyPatch.context() as mp: oder denken Sie daran, undo() explizit aufzurufen.

classmethod with context()

Kontextmanager, der ein neues MonkeyPatch Objekt zurückgibt, das alle im with Block durchgeführten Patches beim Beenden rückgängig macht.

Beispiel

import functools


def test_partial(monkeypatch):
    with monkeypatch.context() as m:
        m.setattr(functools, "partial", 3)

Nützlich in Situationen, in denen einige Patches vor dem Ende des Tests rückgängig gemacht werden sollen, z. B. das Mocken von stdlib Funktionen, die pytest selbst stören könnten, wenn sie gemockt werden (Beispiele hierfür finden Sie unter #3290).

setattr(target: str, name: object, value: ~_pytest.monkeypatch.Notset = <notset>, raising: bool = True) → None

setattr(target: object, name: str, value: object, raising: bool = True) → None

Setzt den Attributwert auf dem Zielobjekt und merkt sich den alten Wert.

Zum Beispiel

import os

monkeypatch.setattr(os, "getcwd", lambda: "/")

Der obige Code ersetzt die Funktion os.getcwd() durch ein lambda, das immer "/" zurückgibt.

Zur Vereinfachung können Sie einen String als target angeben, der als gepunkteter Importpfad interpretiert wird, wobei der letzte Teil der Attributname ist.

monkeypatch.setattr("os.getcwd", lambda: "/")

Löst AttributeError aus, wenn das Attribut nicht existiert, es sei denn, raising ist auf False gesetzt.

Wo man patchen soll

monkeypatch.setattr funktioniert, indem es das Objekt, auf das ein Name zeigt, (temporär) durch ein anderes ersetzt. Es kann viele Namen geben, die auf ein einzelnes Objekt zeigen. Damit das Patchen funktioniert, müssen Sie sicherstellen, dass Sie den vom zu testenden System verwendeten Namen patchen.

Siehe den Abschnitt Wo man patchen soll in der Dokumentation zu unittest.mock, die für unittest.mock.patch() bestimmt ist, aber auch für monkeypatch.setattr gilt.

delattr(target, name=<notset>, raising=True)

Löscht das Attribut name aus target.

Wenn kein name angegeben ist und target ein String ist, wird es als gepunkteter Importpfad interpretiert, wobei der letzte Teil der Attributname ist.

Löst AttributeError aus, wenn das Attribut nicht existiert, es sei denn, raising ist auf False gesetzt.

setitem(dic, name, value)

Setzt den Dictionary-Eintrag name auf den Wert.

delitem(dic, name, raising=True)

Löscht name aus dem Dictionary.

Löst KeyError aus, wenn es nicht existiert, es sei denn, raising ist auf False gesetzt.

setenv(name, value, prepend=None)

Setzt die Umgebungsvariable name auf value.

Wenn prepend ein Zeichen ist, wird der aktuelle Umgebungsvariablenwert gelesen und value angehängt, das mit dem prepend Zeichen verbunden ist.

delenv(name, raising=True)

Löscht name aus der Umgebung.

Löst KeyError aus, wenn es nicht existiert, es sei denn, raising ist auf False gesetzt.

syspath_prepend(path)

Fügt den Pfad am Anfang der Liste der Importorte in sys.path ein.

chdir(path)

Ändert das aktuelle Arbeitsverzeichnis in den angegebenen Pfad.

Parameter:

path (str | PathLike[str]) – Der Pfad, in den gewechselt werden soll.

undo()

Macht vorherige Änderungen rückgängig.

Dieser Aufruf leert den Undo-Stack. Ein erneuter Aufruf hat keine Auswirkungen, es sei denn, Sie nehmen nach dem Undo-Aufruf weitere Monkey-Patches vor.

Normalerweise ist es nicht notwendig, undo() aufzurufen, da dies beim Abbau automatisch geschieht.

Hinweis

Dasselbe monkeypatch Fixture wird während einer einzelnen Testfunktionsausführung verwendet. Wenn monkeypatch sowohl von der Testfunktion selbst als auch von einem der Test-Fixtures verwendet wird, macht ein Aufruf von undo() alle von beiden Funktionen vorgenommenen Änderungen rückgängig.

Bevorzugen Sie die Verwendung von context().

pytestconfig

pytestconfig()

Session-basiertes Fixture, das das pytest.Config Objekt der Sitzung zurückgibt.

Beispiel

def test_foo(pytestconfig):
    if pytestconfig.get_verbosity() > 0:
        ...

pytester

Hinzugefügt in Version 6.2.

Stellt eine Pytester Instanz bereit, die zum Ausführen und Testen von pytest selbst verwendet werden kann.

Es stellt ein leeres Verzeichnis bereit, in dem pytest isoliert ausgeführt werden kann, und enthält Einrichtungen zum Schreiben von Tests, Konfigurationsdateien und zum Abgleichen mit der erwarteten Ausgabe.

Um es zu verwenden, fügen Sie es Ihrer obersten conftest.py Datei hinzu.

pytest_plugins = "pytester"

final class Pytester

Einrichtungen zum Schreiben von Tests/Konfigurationsdateien, Ausführen von pytest in Isolation und Abgleichen mit der erwarteten Ausgabe, perfekt für Black-Box-Tests von pytest-Plugins.

Es versucht, den Testlauf so weit wie möglich von externen Faktoren zu isolieren, indem es das aktuelle Arbeitsverzeichnis auf path und Umgebungsvariablen während der Initialisierung setzt.

exception TimeoutExpired

plugins: list[str | object]

Eine Liste von Plugins, die mit parseconfig() und runpytest() verwendet werden sollen. Anfangs ist dies eine leere Liste, aber Plugins können der Liste hinzugefügt werden.

Wenn im Unterprozessmodus ausgeführt wird, geben Sie Plugins nach Namen (str) an – das Hinzufügen von Plugin-Objekten direkt wird nicht unterstützt.

property path: Path

Temporäres Verzeichnispfad, das zum Erstellen von Dateien/Ausführen von Tests usw. verwendet wird.

make_hook_recorder(pluginmanager)

Erstellt einen neuen HookRecorder für einen PytestPluginManager.

chdir()

Wechselt in das temporäre Verzeichnis.

Dies geschieht automatisch bei der Instanziierung.

makefile(ext, *args, **kwargs)

Erstellt neue Textdatei(en) im Testverzeichnis.

Parameter:

• ext (str) – Die Erweiterung, die die Datei(en) haben soll, einschließlich des Punkts, z. B. .py.

• args (str) – Alle Argumente werden als Strings behandelt und mit Zeilenumbrüchen verbunden. Das Ergebnis wird als Inhalt in die Datei geschrieben. Der Name der Datei basiert auf der Testfunktion, die dieses Fixture anfordert.

• kwargs (str) – Jedes Schlüsselwort ist der Name einer Datei, während der Wert davon in die Datei geschrieben wird.

Gibt zurück:

Die erste erstellte Datei.

Rückgabetyp:

Pfad

Beispiele

pytester.makefile(".txt", "line1", "line2")

pytester.makefile(".ini", pytest="[pytest]\naddopts=-rs\n")

Um Binärdateien zu erstellen, verwenden Sie pathlib.Path.write_bytes() direkt.

filename = pytester.path.joinpath("foo.bin")
filename.write_bytes(b"...")

makeconftest(source)

Schreibt eine conftest.py-Datei.

Parameter:

source (str) – Der Inhalt.

Gibt zurück:

Die conftest.py-Datei.

Rückgabetyp:

Pfad

makeini(source)

Schreibt eine tox.ini-Datei.

Parameter:

source (str) – Der Inhalt.

Gibt zurück:

Die tox.ini-Datei.

Rückgabetyp:

Pfad

maketoml(source)

Schreibt eine pytest.toml-Datei.

Parameter:

source (str) – Der Inhalt.

Gibt zurück:

Die pytest.toml-Datei.

Rückgabetyp:

Pfad

Hinzugefügt in Version 9.0.

getinicfg(source)

Gibt den pytest-Abschnitt aus der tox.ini-Konfigurationsdatei zurück.

makepyprojecttoml(source)

Schreibt eine pyproject.toml-Datei.

Parameter:

source (str) – Der Inhalt.

Gibt zurück:

Die pyproject.ini-Datei.

Rückgabetyp:

Pfad

Hinzugefügt in Version 6.0.

makepyfile(*args, **kwargs)

Verkürzung für .makefile() mit der Erweiterung .py.

Standardmäßig wird der Testname mit der Erweiterung '.py' verwendet, z. B. test_foobar.py, wobei vorhandene Dateien überschrieben werden.

Beispiele

def test_something(pytester):
    # Initial file is created test_something.py.
    pytester.makepyfile("foobar")
    # To create multiple files, pass kwargs accordingly.
    pytester.makepyfile(custom="foobar")
    # At this point, both 'test_something.py' & 'custom.py' exist in the test directory.

maketxtfile(*args, **kwargs)

Verkürzung für .makefile() mit der Erweiterung .txt.

Standardmäßig wird der Testname mit der Erweiterung '.txt' verwendet, z. B. test_foobar.txt, wobei vorhandene Dateien überschrieben werden.

Beispiele

def test_something(pytester):
    # Initial file is created test_something.txt.
    pytester.maketxtfile("foobar")
    # To create multiple files, pass kwargs accordingly.
    pytester.maketxtfile(custom="foobar")
    # At this point, both 'test_something.txt' & 'custom.txt' exist in the test directory.

syspathinsert(path=None)

Fügt einen Verzeichnispfad zu sys.path hinzu, standardmäßig path.

Dies wird beim Sterben dieses Objekts am Ende jedes Tests automatisch rückgängig gemacht.

Parameter:

path (str | PathLike[str] | None) – Der Pfad.

mkdir(name)

Erstellt ein neues (Unter-)Verzeichnis.

Parameter:

name (str | PathLike[str]) – Der Name des Verzeichnisses, relativ zum pytester-Pfad.

Gibt zurück:

Das erstellte Verzeichnis.

Rückgabetyp:

pathlib.Path

mkpydir(name)

Erstellt ein neues Python-Paket.

Dies erstellt ein (Unter-)Verzeichnis mit einer leeren __init__.py-Datei, damit es als Python-Paket erkannt wird.

copy_example(name=None)

Kopiert eine Datei aus dem Projektverzeichnis in das Testverzeichnis.

Parameter:

name (str | None) – Der Name der zu kopierenden Datei.

Gibt zurück:

Pfad zum kopierten Verzeichnis (innerhalb von self.path).

Rückgabetyp:

pathlib.Path

getnode(config, arg)

Ruft den Collection-Knoten einer Datei ab.

Parameter:

• config (Config) – Eine pytest-Konfiguration. Siehe parseconfig() und parseconfigure() zum Erstellen.

• arg (str | PathLike[str]) – Pfad zur Datei.

Gibt zurück:

Der Knoten.

Rückgabetyp:

Collector | Item

getpathnode(path)

Gibt den Collection-Knoten einer Datei zurück.

Dies ist ähnlich wie getnode(), verwendet jedoch parseconfigure(), um die (konfigurierte) pytest Config-Instanz zu erstellen.

Parameter:

path (str | PathLike[str]) – Pfad zur Datei.

Gibt zurück:

Der Knoten.

Rückgabetyp:

Collector | Item

genitems(colitems)

Generiert alle Test-Items aus einem Collection-Knoten.

Dies rekursiert in den Collection-Knoten und gibt eine Liste aller darin enthaltenen Test-Items zurück.

Parameter:

colitems (Sequence[Item | Collector]) – Die Collection-Knoten.

Gibt zurück:

Die gesammelten Items.

Rückgabetyp:

list[Item]

runitem(source)

Führt das „test_func“-Item aus.

Die aufrufende Testinstanz (Klasse, die die Testmethode enthält) muss eine Methode .getrunner() bereitstellen, die einen Runner zurückgibt, der das Testprotokoll für ein einzelnes Item ausführen kann, z.B. _pytest.runner.runtestprotocol.

inline_runsource(source, *cmdlineargs)

Führt ein Testmodul im Prozess mit pytest.main() aus.

Diese Ausführung schreibt „source“ in eine temporäre Datei und führt pytest.main() darauf aus und gibt eine HookRecorder-Instanz für das Ergebnis zurück.

Parameter:

• source (str) – Der Quellcode des Testmoduls.

• cmdlineargs – Zusätzliche Befehlszeilenargumente, die verwendet werden sollen.

inline_genitems(*args)

Führt pytest.main(['--collect-only']) im Prozess aus.

Führt die Funktion pytest.main() aus, um pytest im Testprozess selbst auszuführen, ähnlich wie inline_run(), gibt jedoch ein Tupel der gesammelten Items und eine HookRecorder-Instanz zurück.

inline_run(*args, plugins=(), no_reraise_ctrlc=False)

Führt pytest.main() im Prozess aus und gibt einen HookRecorder zurück.

Führt die Funktion pytest.main() aus, um pytest im Testprozess selbst auszuführen. Das bedeutet, es kann eine HookRecorder-Instanz zurückgeben, die detailliertere Ergebnisse aus dieser Ausführung liefert, als durch Abgleich von stdout/stderr von runpytest() möglich ist.

Parameter:

• args (str | PathLike[str]) – Befehlszeilenargumente, die an pytest.main() übergeben werden.

• plugins – Zusätzliche Plugin-Instanzen, die die pytest.main()-Instanz verwenden soll.

• no_reraise_ctrlc (bool) – Normalerweise lösen wir KeyboardInterrupts aus dem Kindlauf erneut aus. Wenn True, wird die KeyboardInterrupt-Ausnahme abgefangen.

runpytest_inprocess(*args, **kwargs)

Gibt das Ergebnis der Ausführung von pytest im Prozess zurück und bietet eine ähnliche Schnittstelle wie self.runpytest().

runpytest(*args, **kwargs)

Führt pytest inline oder in einem Subprozess aus, abhängig von der Befehlszeilenoption „–runpytest“, und gibt ein RunResult zurück.

parseconfig(*args)

Gibt eine neue pytest pytest.Config-Instanz aus den gegebenen Befehlszeilenargumenten zurück.

Dies ruft den pytest-Bootstrapping-Code in _pytest.config auf, um einen neuen pytest.PytestPluginManager zu erstellen und den Hook pytest_cmdline_parse aufzurufen, um eine neue pytest.Config-Instanz zu erstellen.

Wenn plugins mit Modulen gefüllt wurde, sollten diese mit dem Plugin-Manager registriert werden.

parseconfigure(*args)

Gibt eine neue, konfigurierte Config-Instanz von pytest zurück.

Gibt eine neue pytest.Config-Instanz zurück, ähnlich wie parseconfig(), ruft aber auch den Hook pytest_configure auf.

getitem(source, funcname='test_func')

Gibt das Test-Item für eine Testfunktion zurück.

Schreibt den Quellcode in eine Python-Datei und führt die pytest-Sammlung auf dem resultierenden Modul aus. Gibt das Test-Item für den angeforderten Funktionsnamen zurück.

Parameter:

• source (str | PathLike[str]) – Der Modulquellcode.

• funcname (str) – Der Name der Testfunktion, für die ein Test-Item zurückgegeben werden soll.

Gibt zurück:

Das Test-Item.

Rückgabetyp:

Item

getitems(source)

Gibt alle aus dem Modul gesammelten Test-Items zurück.

Schreibt den Quellcode in eine Python-Datei und führt die pytest-Sammlung auf dem resultierenden Modul aus, wobei alle darin enthaltenen Test-Items zurückgegeben werden.

getmodulecol(source, configargs=(), *, withinit=False)

Gibt den Modul-Collection-Knoten für source zurück.

Schreibt source mit makepyfile() in eine Datei und führt dann die pytest-Sammlung darauf aus, wobei der Collection-Knoten für das Testmodul zurückgegeben wird.

Parameter:

• source (str | PathLike[str]) – Der Quellcode des zu sammelnden Moduls.

• configargs – Zusätzliche Argumente, die an parseconfigure() übergeben werden sollen.

• withinit (bool) – Ob auch eine __init__.py-Datei im selben Verzeichnis geschrieben werden soll, um sicherzustellen, dass es sich um ein Paket handelt.

collect_by_name(modcol, name)

Gibt den Collection-Knoten für den Namen aus der Modul-Collection zurück.

Durchsucht einen Modul-Collection-Knoten nach einem Collection-Knoten, der dem gegebenen Namen entspricht.

Parameter:

• modcol (Collector) – Ein Modul-Collection-Knoten; siehe getmodulecol().

• name (str) – Der Name des zurückzugebenden Knotens.

popen(cmdargs, stdout=-1, stderr=-1, stdin=NotSetType.token, **kw)

Ruft subprocess.Popen auf.

Ruft subprocess.Popen auf und stellt sicher, dass das aktuelle Arbeitsverzeichnis in PYTHONPATH enthalten ist.

Sie sollten wahrscheinlich stattdessen run() verwenden.

run(*cmdargs, timeout=None, stdin=NotSetType.token)

Führt einen Befehl mit Argumenten aus.

Führt einen Prozess mit subprocess.Popen aus und speichert stdout und stderr.

Parameter:

• cmdargs (str | PathLike[str]) – Die Sequenz von Argumenten, die an subprocess.Popen übergeben werden, wobei Pfad-Objekte automatisch in str konvertiert werden.

• timeout (float | None) – Der Zeitraum in Sekunden, nach dem ein Timeout auftritt und Pytester.TimeoutExpired ausgelöst wird.

• stdin (_pytest.compat.NotSetType | bytes | IO[Any] | int) –

  Optionaler Standardeingang.

  • Wenn es sich um CLOSE_STDIN (Standard) handelt, ruft diese Methode subprocess.Popen mit stdin=subprocess.PIPE auf und der Standardeingang wird sofort nach dem Start des neuen Befehls geschlossen.

  • Wenn es vom Typ bytes ist, werden diese Bytes an den Standardeingang des Befehls gesendet.

  • Andernfalls wird es an subprocess.Popen übergeben. Für weitere Informationen in diesem Fall konsultieren Sie das Dokument des stdin-Parameters in subprocess.Popen.

Gibt zurück:

Das Ergebnis.

Rückgabetyp:

RunResult

runpython(script)

Führt ein Python-Skript mit sys.executable als Interpreter aus.

runpython_c(command)

Führt python -c "command" aus.

runpytest_subprocess(*args, timeout=None)

Führt pytest als Subprozess mit den angegebenen Argumenten aus.

Alle zu der Liste plugins hinzugefügten Plugins werden über die Befehlszeilenoption -p hinzugefügt. Zusätzlich wird --basetemp verwendet, um temporäre Dateien und Verzeichnisse in einem nummerierten Verzeichnis mit dem Präfix „runpytest-“ abzulegen, um Konflikte mit der normalen nummerierten pytest-Speicherort für temporäre Dateien und Verzeichnisse zu vermeiden.

Parameter:

• args (str | PathLike[str]) – Die Sequenz von Argumenten, die an den pytest-Subprozess übergeben werden.

• timeout (float | None) – Der Zeitraum in Sekunden, nach dem ein Timeout auftritt und Pytester.TimeoutExpired ausgelöst wird.

Gibt zurück:

Das Ergebnis.

Rückgabetyp:

RunResult

spawn_pytest(string, expect_timeout=10.0)

Führt pytest mit pexpect aus.

Dies stellt sicher, dass das richtige pytest verwendet wird und richtet die temporären Verzeichnisspeicherorte ein.

Das pexpect-Kind wird zurückgegeben.

spawn(cmd, expect_timeout=10.0)

Führt einen Befehl mit pexpect aus.

Das pexpect-Kind wird zurückgegeben.

final class RunResult

Das Ergebnis der Ausführung eines Befehls von Pytester.

ret: int | ExitCode

Der Rückgabewert.

outlines

Liste der Zeilen, die von stdout erfasst wurden.

errlines

Liste der Zeilen, die von stderr erfasst wurden.

stdout

LineMatcher der stdout-Ausgabe.

Verwenden Sie z.B. str(stdout), um stdout zu rekonstruieren, oder die gebräuchliche Methode stdout.fnmatch_lines().

stderr

LineMatcher der stderr-Ausgabe.

duration

Dauer in Sekunden.

parseoutcomes()

Gibt ein Wörterbuch von Ergebnis-Nomen -> Anzahl zurück, das aus der Analyse der Terminalausgabe des Testprozesses erstellt wird.

Die zurückgegebenen Nomen sind immer im Plural

======= 1 failed, 1 passed, 1 warning, 1 error in 0.13s ====

Gibt {"failed": 1, "passed": 1, "warnings": 1, "errors": 1} zurück.

classmethod parse_summary_nouns(lines)

Extrahieren Sie die Nomen aus einer Pytest-Terminal-Zusammenfassungszeile.

Es wird immer das Plural-Nomen zur Konsistenz zurückgegeben

======= 1 failed, 1 passed, 1 warning, 1 error in 0.13s ====

Gibt {"failed": 1, "passed": 1, "warnings": 1, "errors": 1} zurück.

assert_outcomes(passed=0, skipped=0, failed=0, errors=0, xpassed=0, xfailed=0, warnings=None, deselected=None)

Stellt sicher, dass die angegebenen Ergebnisse mit den jeweiligen Zahlen (0 bedeutet, dass sie nicht aufgetreten sind) in der Textausgabe eines Testlaufs erscheinen.

warnings und deselected werden nur geprüft, wenn sie nicht None sind.

class LineMatcher

Flexible Textüberprüfung.

Dies ist eine Hilfsklasse zum Testen großer Texte wie der Ausgabe von Befehlen.

Der Konstruktor nimmt eine Liste von Zeilen ohne ihre abschließenden Zeilenumbrüche entgegen, d.h. text.splitlines().

__str__()

Gibt den gesamten Originaltext zurück.

Hinzugefügt in Version 6.2: Sie können str() in älteren Versionen verwenden.

fnmatch_lines_random(lines2)

Prüft, ob Zeilen in der Ausgabe in beliebiger Reihenfolge vorhanden sind (unter Verwendung von fnmatch.fnmatch()).

re_match_lines_random(lines2)

Prüft, ob Zeilen in der Ausgabe in beliebiger Reihenfolge vorhanden sind (unter Verwendung von re.match()).

get_lines_after(fnline)

Gibt alle Zeilen zurück, die der gegebenen Zeile im Text folgen.

Die gegebene Zeile kann Glob-Wildcards enthalten.

fnmatch_lines(lines2, *, consecutive=False)

Prüft, ob Zeilen in der Ausgabe vorhanden sind (unter Verwendung von fnmatch.fnmatch()).

Das Argument ist eine Liste von Zeilen, die übereinstimmen müssen und Glob-Wildcards verwenden können. Wenn sie nicht übereinstimmen, wird pytest.fail() aufgerufen. Die Übereinstimmungen und Nicht-Übereinstimmungen werden ebenfalls als Teil der Fehlermeldung angezeigt.

Parameter:

• lines2 (Sequence[str]) – Zeichenfolgenmuster, die übereinstimmen sollen.

• consecutive (bool) – Zeilen nacheinander übereinstimmen?

re_match_lines(lines2, *, consecutive=False)

Prüft, ob Zeilen in der Ausgabe vorhanden sind (unter Verwendung von re.match()).

Das Argument ist eine Liste von Zeilen, die mit re.match übereinstimmen müssen. Wenn sie nicht übereinstimmen, wird pytest.fail() aufgerufen.

Die Übereinstimmungen und Nicht-Übereinstimmungen werden ebenfalls als Teil der Fehlermeldung angezeigt.

Parameter:

• lines2 (Sequence[str]) – Zeichenfolgenmuster, die übereinstimmen sollen.

• consecutive (bool) – Zeilen nacheinander übereinstimmen?

no_fnmatch_line(pat)

Stellen Sie sicher, dass erfasste Zeilen nicht mit dem angegebenen Muster übereinstimmen, unter Verwendung von fnmatch.fnmatch.

Parameter:

pat (str) – Das Muster, mit dem Zeilen übereinstimmen sollen.

no_re_match_line(pat)

Stellen Sie sicher, dass erfasste Zeilen nicht mit dem angegebenen Muster übereinstimmen, unter Verwendung von re.match.

Parameter:

pat (str) – Der reguläre Ausdruck, mit dem Zeilen übereinstimmen sollen.

str()

Gibt den gesamten Originaltext zurück.

final class HookRecorder

Zeichnet alle in einem Plugin-Manager aufgerufenen Hooks auf.

Hook-Recorder werden von Pytester erstellt.

Dies wickelt alle Hook-Aufrufe im Plugin-Manager ein, zeichnet jeden Aufruf auf, bevor die normalen Aufrufe weitergeleitet werden.

getcalls(names)

Rufen Sie alle aufgezeichneten Aufrufe von Hooks mit den angegebenen Namen (oder Namen) ab.

matchreport(inamepart='', names=('pytest_runtest_logreport', 'pytest_collectreport'), when=None)

Gibt einen Testreport zurück, dessen gepunkteter Importpfad übereinstimmt.

final class RecordedHookCall

Ein aufgezeichneter Hook-Aufruf.

Die Argumente des Hook-Aufrufs werden als Attribute gesetzt. Zum Beispiel

calls = hook_recorder.getcalls("pytest_runtest_setup")
# Suppose pytest_runtest_setup was called once with `item=an_item`.
assert calls[0].item is an_item

record_property

Tutorial: record_property

record_property()

Fügt zusätzliche Eigenschaften zum aufrufenden Test hinzu.

Benutzereigenschaften werden Teil des Testreports und sind für konfigurierte Reporter, wie JUnit XML, verfügbar.

Die Fixture ist aufrufbar mit name, value. Der Wert wird automatisch XML-kodiert.

Beispiel

def test_function(record_property):
    record_property("example_key", 1)

record_testsuite_property

Tutorial: record_testsuite_property

record_testsuite_property()

Zeichnet ein neues <property>-Tag als Kind des Wurzel-<testsuite>-Elements auf.

Dies eignet sich zum Schreiben globaler Informationen über die gesamte Testsuite und ist mit der xunit2 JUnit-Familie kompatibel.

Dies ist eine Fixture mit Session-Scope, die mit (name, value) aufgerufen wird. Beispiel

def test_foo(record_testsuite_property):
    record_testsuite_property("ARCH", "PPC")
    record_testsuite_property("STORAGE_TYPE", "CEPH")

Parameter:

• name – Der Name der Eigenschaft.

• value – Der Wert der Eigenschaft. Wird in eine Zeichenfolge konvertiert.

Warnung

Derzeit funktioniert diese Fixture **nicht** mit dem Plugin pytest-xdist. Siehe #7767 für Details.

recwarn

Tutorial: Warnungen aufzeichnen

recwarn()

Gibt eine WarningsRecorder-Instanz zurück, die alle von Testfunktionen ausgegebenen Warnungen aufzeichnet.

Informationen zu Warnungskategorien finden Sie unter Wie man Warnungen abfängt.

class WarningsRecorder

Ein Kontextmanager zur Aufzeichnung von ausgelösten Warnungen.

Jede aufgezeichnete Warnung ist eine Instanz von warnings.WarningMessage.

Angepasst von warnings.catch_warnings.

Hinweis

DeprecationWarning und PendingDeprecationWarning werden unterschiedlich behandelt; siehe Sicherstellen, dass eine Funktion eine Deprecation-Warnung auslöst.

property list: list[WarningMessage]

Die Liste der aufgezeichneten Warnungen.

__getitem__(i)

Ruft eine aufgezeichnete Warnung nach Index ab.

__iter__()

Iteriert durch die aufgezeichneten Warnungen.

__len__()

Die Anzahl der aufgezeichneten Warnungen.

pop(cls=<class 'Warning'>)

Entfernt die erste aufgezeichnete Warnung, die eine Instanz von cls ist, aber keine Instanz einer Unterklasse einer anderen Übereinstimmung. Löst AssertionError aus, wenn keine Übereinstimmung gefunden wird.

clear()

Löscht die Liste der aufgezeichneten Warnungen.

request

Beispiel: Unterschiedliche Werte an eine Testfunktion übergeben, abhängig von Kommandozeilenoptionen

Die request-Fixture ist eine spezielle Fixture, die Informationen über die anfragende Testfunktion bereitstellt.

class FixtureRequest

Der Typ der request-Fixture.

Ein Request-Objekt bietet Zugriff auf den anfragenden Testkontext und hat ein param-Attribut, falls die Fixture parametrisiert ist.

fixturename: Final

Die Fixture, für die diese Anfrage durchgeführt wird.

property scope: Literal['session', 'package', 'module', 'class', 'function']

Scope-Zeichenkette, eine von "function", "class", "module", "package", "session".

property fixturenames: list[str]

Namen aller aktiven Fixtures in dieser Anfrage.

abstractmethod node

Zugrundeliegender Sammlungsknoten (abhängig vom aktuellen Anfragescope).

property config: Config

Das Pytest-Konfigurationsobjekt, das dieser Anfrage zugeordnet ist.

property function

Testfunktions-Objekt, wenn die Anfrage einen Scope pro Funktion hat.

property cls

Klasse (kann None sein), in der die Testfunktion gesammelt wurde.

property instance

Instanz (kann None sein), auf der die Testfunktion gesammelt wurde.

property module

Python-Modulobjekt, in dem die Testfunktion gesammelt wurde.

property path: Path

Pfad, an dem die Testfunktion gesammelt wurde.

property keywords: MutableMapping[str, Any]

Schlüsselwörter/Marker-Wörterbuch für den zugrundeliegenden Knoten.

property session: Session

Pytest-Session-Objekt.

abstractmethod addfinalizer(finalizer)

Fügt eine Finalizer-/Aufräumfunktion hinzu, die nach Ausführung des letzten Tests im anfragenden Testkontext ohne Argumente aufgerufen wird.

applymarker(marker)

Wendet einen Marker auf eine einzelne Testfunktionsausführung an.

Diese Methode ist nützlich, wenn Sie keine Schlüsselwort/Marker für alle Funktionsaufrufe haben möchten.

Parameter:

marker (str | MarkDecorator) – Ein Objekt, das durch einen Aufruf von pytest.mark.NAME(...) erstellt wurde.

raiseerror(msg)

Löst eine FixtureLookupError-Ausnahme aus.

Parameter:

msg (str | None) – Eine optionale benutzerdefinierte Fehlermeldung.

getfixturevalue(argname)

Dynamisches Ausführen einer benannten Fixture-Funktion.

Die Deklaration von Fixtures über Funktionsargumente wird nach Möglichkeit empfohlen. Wenn Sie jedoch erst zur Test-Setup-Zeit entscheiden können, ob eine andere Fixture verwendet werden soll, können Sie diese Funktion verwenden, um sie innerhalb einer Fixture- oder Testfunktions-Body abzurufen.

Diese Methode kann während der Test-Setup-Phase oder der Testlaufphase verwendet werden, aber während der Test-Teardown-Phase ist der Wert einer Fixture möglicherweise nicht verfügbar.

Parameter:

argname (str) – Der Name der Fixture.

Löst aus:

pytest.FixtureLookupError – Wenn die gegebene Fixture nicht gefunden werden konnte.

subtests

Die subtests-Fixture ermöglicht die Deklaration von Subtests innerhalb von Testfunktionen.

Tutorial: Wie man Subtests verwendet

class Subtests

Subtests fixture, ermöglicht die Deklaration von Subtests innerhalb von Testfunktionen über die test() Methode.

test(msg=None, **kwargs)

Context Manager für Subtests, der Ausnahmen abfängt, die innerhalb des Subtest-Scopes ausgelöst werden, und Assertionsfehler und Fehler einzeln meldet.

Verwendung

def test(subtests):
    for i in range(5):
        with subtests.test("custom message", i=i):
            assert i % 2 == 0

param msg:

Wenn angegeben, wird die Nachricht im Testbericht im Falle eines Subtest-Fehlers angezeigt.

param kwargs:

Beliebige Werte, die ebenfalls dem Subtest-Bericht hinzugefügt werden.

testdir

Identisch mit pytester, stellt aber eine Instanz bereit, deren Methoden Legacy-Objekte vom Typ py.path.local zurückgeben, wenn zutreffend.

Neuer Code sollte die Verwendung von testdir zugunsten von pytester vermeiden.

final class Testdir

Ähnlich wie Pytester, aber diese Klasse arbeitet stattdessen mit Legacy-Objekten vom Typ legacy_path.

Alle Methoden leiten einfach an eine interne Pytester-Instanz weiter und konvertieren Ergebnisse bei Bedarf in legacy_path-Objekte.

exception TimeoutExpired

property tmpdir: LocalPath

Temporäres Verzeichnis, in dem Tests ausgeführt werden.

make_hook_recorder(pluginmanager)

Siehe Pytester.make_hook_recorder().

chdir()

Siehe Pytester.chdir().

makefile(ext, *args, **kwargs)

Siehe Pytester.makefile().

makeconftest(source)

Siehe Pytester.makeconftest().

makeini(source)

Siehe Pytester.makeini().

getinicfg(source)

Siehe Pytester.getinicfg().

makepyprojecttoml(source)

Siehe Pytester.makepyprojecttoml().

makepyfile(*args, **kwargs)

Siehe Pytester.makepyfile().

maketxtfile(*args, **kwargs)

Siehe Pytester.maketxtfile().

syspathinsert(path=None)

Siehe Pytester.syspathinsert().

mkdir(name)

Siehe Pytester.mkdir().

mkpydir(name)

Siehe Pytester.mkpydir().

copy_example(name=None)

Siehe Pytester.copy_example().

getnode(config, arg)

Siehe Pytester.getnode().

getpathnode(path)

Siehe Pytester.getpathnode().

genitems(colitems)

Siehe Pytester.genitems().

runitem(source)

Siehe Pytester.runitem().

inline_runsource(source, *cmdlineargs)

Siehe Pytester.inline_runsource().

inline_genitems(*args)

Siehe Pytester.inline_genitems().

inline_run(*args, plugins=(), no_reraise_ctrlc=False)

Siehe Pytester.inline_run().

runpytest_inprocess(*args, **kwargs)

Siehe Pytester.runpytest_inprocess().

runpytest(*args, **kwargs)

Siehe Pytester.runpytest().

parseconfig(*args)

Siehe Pytester.parseconfig().

parseconfigure(*args)

Siehe Pytester.parseconfigure().

getitem(source, funcname='test_func')

Siehe Pytester.getitem().

getitems(source)

Siehe Pytester.getitems().

getmodulecol(source, configargs=(), withinit=False)

Siehe Pytester.getmodulecol().

collect_by_name(modcol, name)

Siehe Pytester.collect_by_name().

popen(cmdargs, stdout=-1, stderr=-1, stdin=NotSetType.token, **kw)

Siehe Pytester.popen().

run(*cmdargs, timeout=None, stdin=NotSetType.token)

Siehe Pytester.run().

runpython(script)

Siehe Pytester.runpython().

runpython_c(command)

Siehe Pytester.runpython_c().

runpytest_subprocess(*args, timeout=None)

Siehe Pytester.runpytest_subprocess().

spawn_pytest(string, expect_timeout=10.0)

Siehe Pytester.spawn_pytest().

spawn(cmd, expect_timeout=10.0)

Siehe Pytester.spawn().

tmp_path

Tutorial: Anleitung zur Verwendung von temporären Verzeichnissen und Dateien in Tests

tmp_path()

Gibt ein temporäres Verzeichnis (als pathlib.Path-Objekt) zurück, das für jede Testfunktionsausführung eindeutig ist. Das temporäre Verzeichnis wird als Unterverzeichnis des Basis-Temporärverzeichnisses erstellt, mit konfigurierbarer Aufbewahrung, wie in Speicherort und Aufbewahrung temporärer Verzeichnisse besprochen.

tmp_path_factory

Tutorial: Die tmp_path_factory Fixture

tmp_path_factory ist eine Instanz von TempPathFactory

final class TempPathFactory

Factory für temporäre Verzeichnisse unter dem gemeinsamen Basis-Temporärverzeichnis, wie in Speicherort und Aufbewahrung temporärer Verzeichnisse besprochen.

mktemp(basename, numbered=True)

Erstellt ein neues temporäres Verzeichnis, das von der Factory verwaltet wird.

Parameter:

• basename (str) – Basisname des Verzeichnisses, muss ein relativer Pfad sein.

• numbered (bool) – Wenn True, wird sichergestellt, dass das Verzeichnis eindeutig ist, indem ein nummerierter Suffix größer als jeder vorhandene hinzugefügt wird: basename="foo-" und numbered=True bedeutet, dass diese Funktion Verzeichnisse namens "foo-0", "foo-1", "foo-2" und so weiter erstellt.

Gibt zurück:

Der Pfad zum neuen Verzeichnis.

Rückgabetyp:

Pfad

getbasetemp()

Gibt das Basis-Temporärverzeichnis zurück und erstellt es bei Bedarf.

Gibt zurück:

Das Basis-Temporärverzeichnis.

Rückgabetyp:

Pfad

tmpdir

Tutorial: Die tmpdir und tmpdir_factory Fixtures

tmpdir()

Gibt ein temporäres Verzeichnis (als Objekt vom Typ legacy_path) zurück, das für jede Testfunktionsausführung eindeutig ist. Das temporäre Verzeichnis wird als Unterverzeichnis des Basis-Temporärverzeichnisses erstellt, mit konfigurierbarer Aufbewahrung, wie in Speicherort und Aufbewahrung temporärer Verzeichnisse besprochen.

Hinweis

Heutzutage wird die Verwendung von tmp_path bevorzugt.

Über die tmpdir und tmpdir_factory Fixtures.

tmpdir_factory

Tutorial: Die tmpdir und tmpdir_factory Fixtures

tmpdir_factory ist eine Instanz von TempdirFactory

final class TempdirFactory

Backward-Kompatibilitäts-Wrapper, der py.path.local für TempPathFactory implementiert.

Hinweis

Heutzutage wird die Verwendung von tmp_path_factory bevorzugt.

Über die tmpdir und tmpdir_factory Fixtures.

mktemp(basename, numbered=True)

Identisch mit TempPathFactory.mktemp(), gibt aber ein py.path.local Objekt zurück.

getbasetemp()

Identisch mit TempPathFactory.getbasetemp(), gibt aber ein py.path.local Objekt zurück.

Hooks

Tutorial: Schreiben von Plugins

Referenz zu allen Hooks, die von conftest.py Dateien und Plugins implementiert werden können.

@pytest.hookimpl

@pytest.hookimpl

Pytest's Dekorator zum Markieren von Funktionen als Hook-Implementierungen.

Siehe Schreiben von Hook-Funktionen und pluggy.HookimplMarker().

@pytest.hookspec

@pytest.hookspec

Pytest's Decorator zum Markieren von Funktionen als Hook-Spezifikationen.

Siehe Deklarieren neuer Hooks und pluggy.HookspecMarker().

Bootstrapping-Hooks

Bootstrapping-Hooks, die für früh genug registrierte Plugins (interne und Drittanbieter-Plugins) aufgerufen werden.

pytest_load_initial_conftests(early_config, parser, args)

Aufgerufen, um das Laden von initialen conftest-Dateien vor dem Parsen von Kommandozeilenoptionen zu implementieren.

Parameter:

• early_config (Config) – Das Pytest-Konfigurationsobjekt.

• args (Liste[str]) – Argumente, die über die Kommandozeile übergeben werden.

• parser (Parser) – Zum Hinzufügen von Kommandozeilenoptionen.

Verwendung in conftest-Plugins

Dieser Hook wird nicht für conftest-Dateien aufgerufen.

pytest_cmdline_parse(pluginmanager, args)

Gibt ein initialisiertes Config zurück, das die angegebenen Argumente parst.

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis.

Hinweis

Dieser Hook wird nur für Plugin-Klassen aufgerufen, die über das Argument plugins übergeben werden, wenn pytest.main zum Ausführen eines Tests im Prozess verwendet wird.

Parameter:

• pluginmanager (PytestPluginManager) – Der Pytest-Plugin-Manager.

• args (Liste[str]) – Liste der über die Kommandozeile übergebenen Argumente.

Gibt zurück:

Ein Pytest-Konfigurationsobjekt.

Rückgabetyp:

Config | None

Verwendung in conftest-Plugins

Dieser Hook wird nicht für conftest-Dateien aufgerufen.

pytest_cmdline_main(config)

Aufgerufen, um die Hauptaktion der Kommandozeile durchzuführen.

Die Standardimplementierung ruft die Konfigurations-Hooks und pytest_runtestloop auf.

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis.

Parameter:

config (Config) – Das Pytest-Konfigurationsobjekt.

Gibt zurück:

Der Exit-Code.

Rückgabetyp:

ExitCode | int | None

Verwendung in conftest-Plugins

Dieser Hook wird nur für initiale conftests aufgerufen.

Initialisierungs-Hooks

Initialisierungs-Hooks, die für Plugins und conftest.py-Dateien aufgerufen werden.

pytest_addoption(parser, pluginmanager)

Registriert argparse-ähnliche Optionen und Konfigurationswerte, wird einmal zu Beginn einer Testausführung aufgerufen.

Parameter:

• parser (Parser) – Zum Hinzufügen von Kommandozeilenoptionen, rufen Sie parser.addoption(...) auf. Zum Hinzufügen von Konfigurationsdateiwerten rufen Sie parser.addini(...) auf.

• pluginmanager (PytestPluginManager) – Der Pytest-Plugin-Manager, der verwendet werden kann, um hookspec()s oder hookimpl()s zu installieren und es einem Plugin zu ermöglichen, die Hooks eines anderen Plugins aufzurufen, um zu ändern, wie Kommandozeilenoptionen hinzugefügt werden.

Optionen können später über das config-Objekt abgerufen werden, bzw.

• config.getoption(name), um den Wert einer Kommandozeilenoption abzurufen.

• config.getini(name), um einen aus einer Konfigurationsdatei gelesenen Wert abzurufen.

Das Konfigurationsobjekt wird über das Attribut .config an viele interne Objekte übergeben oder kann als Fixture pytestconfig abgerufen werden.

Hinweis

Dieser Hook ist inkompatibel mit Hook-Wrappern.

Verwendung in conftest-Plugins

Wenn ein conftest-Plugin diesen Hook implementiert, wird es sofort aufgerufen, wenn das conftest registriert wird.

Dieser Hook wird nur für initiale conftests aufgerufen.

pytest_addhooks(pluginmanager)

Wird zur Plugin-Registrierungszeit aufgerufen, um das Hinzufügen neuer Hooks durch einen Aufruf von pluginmanager.add_hookspecs(module_or_class, prefix) zu ermöglichen.

Parameter:

pluginmanager (PytestPluginManager) – Der Pytest-Plugin-Manager.

Hinweis

Dieser Hook ist inkompatibel mit Hook-Wrappern.

Verwendung in conftest-Plugins

Wenn ein conftest-Plugin diesen Hook implementiert, wird es sofort aufgerufen, wenn das conftest registriert wird.

pytest_configure(config)

Ermöglicht Plugins und conftest-Dateien, die initiale Konfiguration durchzuführen.

Hinweis

Dieser Hook ist inkompatibel mit Hook-Wrappern.

Parameter:

config (Config) – Das Pytest-Konfigurationsobjekt.

Verwendung in conftest-Plugins

Dieser Hook wird für jede initiale conftest-Datei aufgerufen, nachdem die Kommandozeilenoptionen geparst wurden. Danach wird der Hook für andere conftest-Dateien aufgerufen, wenn sie registriert werden.

pytest_unconfigure(config)

Wird aufgerufen, bevor der Testprozess beendet wird.

Parameter:

config (Config) – Das Pytest-Konfigurationsobjekt.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren.

pytest_sessionstart(session)

Wird aufgerufen, nachdem das Session-Objekt erstellt wurde und bevor die Sammlung durchgeführt und die Testschleife gestartet wird.

Parameter:

session (Session) – Das Pytest-Sitzungsobjekt.

Verwendung in conftest-Plugins

Dieser Hook wird nur für initiale conftests aufgerufen.

pytest_sessionfinish(session, exitstatus)

Wird aufgerufen, nachdem die gesamte Testausführung abgeschlossen ist, kurz bevor der Exit-Status an das System zurückgegeben wird.

Parameter:

• session (Session) – Das Pytest-Sitzungsobjekt.

• exitstatus (int | ExitCode) – Der Status, den Pytest an das System zurückgibt.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren.

pytest_plugin_registered(plugin, plugin_name, manager)

Ein neues Pytest-Plugin wurde registriert.

Parameter:

• plugin (_PluggyPlugin) – Das Plugin-Modul oder die Plugin-Instanz.

• plugin_name (str) – Der Name, unter dem das Plugin registriert ist.

• manager (PytestPluginManager) – Der Pytest-Plugin-Manager.

Hinweis

Dieser Hook ist inkompatibel mit Hook-Wrappern.

Verwendung in conftest-Plugins

Wenn ein conftest-Plugin diesen Hook implementiert, wird es sofort aufgerufen, wenn das conftest registriert wird, einmal für jedes bisher registrierte Plugin (einschließlich sich selbst!) und danach für alle Plugins, wenn sie registriert werden.

Sammlungs-Hooks

pytest ruft die folgenden Hooks zum Sammeln von Dateien und Verzeichnissen auf

pytest_collection(session)

Führt die Sammelphase für die gegebene Sitzung durch.

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis. Der Rückgabewert wird nicht verwendet, stoppt aber nur die weitere Verarbeitung.

Die Standard-Sammelphase ist diese (siehe einzelne Hooks für vollständige Details)

1. Ausgehend von session als anfänglicher Sammler

1. pytest_collectstart(collector)

2. report = pytest_make_collect_report(collector)

3. pytest_exception_interact(collector, call, report), wenn eine interaktive Ausnahme auftrat

4. Für jeden gesammelten Knoten

1. Wenn ein Element, pytest_itemcollected(item)

2. Wenn ein Sammler, rekursiv aufrufen.

5. pytest_collectreport(report)

2. pytest_collection_modifyitems(session, config, items)

1. pytest_deselected(items) für alle abgewählten Elemente (kann mehrmals aufgerufen werden)

3. pytest_collection_finish(session)

4. Setzt session.items auf die Liste der gesammelten Elemente.

5. Setzt session.testscollected auf die Anzahl der gesammelten Elemente.

Sie können diesen Hook implementieren, um nur eine Aktion vor der Sammlung durchzuführen, z. B. das Terminal-Plugin verwendet ihn, um mit der Anzeige des Sammlungszählers zu beginnen (und gibt None zurück).

Parameter:

session (Session) – Das Pytest-Sitzungsobjekt.

Verwendung in conftest-Plugins

Dieser Hook wird nur für initiale conftests aufgerufen.

pytest_ignore_collect(collection_path, path, config)

Gibt True zurück, um diesen Pfad für die Sammlung zu ignorieren.

Gibt None zurück, damit andere Plugins den Pfad für die Sammlung ignorieren.

Die Rückgabe von False wird diesen Pfad *nicht* für die Sammlung ignorieren, ohne anderen Plugins eine Chance zu geben, ihn zu ignorieren.

Dieser Hook wird für alle Dateien und Verzeichnisse abgefragt, bevor spezifischere Hooks aufgerufen werden.

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis.

Parameter:

• collection_path (pathlib.Path) – Der zu analysierende Pfad.

• path (LEGACY_PATH) – Der zu analysierende Pfad (veraltet).

• config (Config) – Das Pytest-Konfigurationsobjekt.

Geändert in Version 7.0.0: Der Parameter collection_path wurde als pathlib.Path-Entsprechung des Parameters path hinzugefügt. Der Parameter path wurde als veraltet markiert.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für einen bestimmten Sammelpfad werden nur conftest-Dateien in übergeordneten Verzeichnissen des Sammelpfads abgefragt (wenn der Pfad ein Verzeichnis ist, wird die eigene conftest-Datei *nicht* abgefragt – ein Verzeichnis kann sich nicht selbst ignorieren!).

pytest_collect_directory(path, parent)

Erstellt einen Collector für das gegebene Verzeichnis oder None, falls nicht relevant.

Hinzugefügt in Version 8.0.

Für beste Ergebnisse sollte der zurückgegebene Sammler eine Unterklasse von Directory sein, dies ist jedoch nicht zwingend erforderlich.

Der neue Knoten muss den angegebenen parent als Elternteil haben.

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis.

Parameter:

path (pathlib.Path) – Der zu analysierende Pfad.

Siehe Verwendung eines benutzerdefinierten Verzeichnissammlers für ein einfaches Anwendungsbeispiel dieses Hooks.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für einen bestimmten Sammelpfad werden nur conftest-Dateien in übergeordneten Verzeichnissen des Sammelpfads abgefragt (wenn der Pfad ein Verzeichnis ist, wird die eigene conftest-Datei *nicht* abgefragt – ein Verzeichnis kann sich nicht selbst sammeln!).

pytest_collect_file(file_path, path, parent)

Erstellt einen Collector für den gegebenen Pfad oder None, falls nicht relevant.

Für beste Ergebnisse sollte der zurückgegebene Sammler eine Unterklasse von File sein, dies ist jedoch nicht zwingend erforderlich.

Der neue Knoten muss den angegebenen parent als Elternteil haben.

Parameter:

• file_path (pathlib.Path) – Der zu analysierende Pfad.

• path (LEGACY_PATH) – Der zu sammelnde Pfad (veraltet).

Geändert in Version 7.0.0: Der Parameter file_path wurde als pathlib.Path-Entsprechung des Parameters path hinzugefügt. Der Parameter path wurde als veraltet markiert.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für einen bestimmten Dateipfad werden nur conftest-Dateien in übergeordneten Verzeichnissen des Dateipfads abgefragt.

pytest_pycollect_makemodule(module_path, path, parent)

Gibt einen pytest.Module-Sammler oder None für den gegebenen Pfad zurück.

Dieser Hook wird für jeden passenden Testmodulpfad aufgerufen. Der Hook pytest_collect_file muss verwendet werden, wenn Sie Testmodule für Dateien erstellen möchten, die nicht als Testmodul passen.

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis.

Parameter:

• module_path (pathlib.Path) – Der zu sammelnde Pfad des Moduls.

• path (LEGACY_PATH) – Der zu sammelnde Pfad des Moduls (veraltet).

Geändert in Version 7.0.0: Der Parameter module_path wurde als pathlib.Path-Entsprechung des Parameters path hinzugefügt.

Der Parameter path wurde zugunsten von fspath als veraltet markiert.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für einen gegebenen übergeordneten Sammler werden nur conftest-Dateien im Verzeichnis des Sammlers und seinen übergeordneten Verzeichnissen abgefragt.

Um die Sammlung von Objekten in Python-Modulen zu beeinflussen, können Sie den folgenden Hook verwenden

pytest_pycollect_makeitem(collector, name, obj)

Gibt ein benutzerdefiniertes Element/Sammler für ein Python-Objekt in einem Modul zurück oder None.

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis.

Parameter:

• collector (Module | Class) – Der Modul-/Klassensammler.

• name (str) – Der Name des Objekts im Modul/in der Klasse.

• obj (object) – Das Objekt.

Gibt zurück:

Die erstellten Elemente/Sammler.

Rückgabetyp:

None | Item | Collector | Liste[Item | Collector]

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für einen gegebenen Sammler werden nur conftest-Dateien im Verzeichnis des Sammlers und seinen übergeordneten Verzeichnissen abgefragt.

pytest_generate_tests(metafunc)

Generiert (mehrere) parametrisierte Aufrufe einer Testfunktion.

Parameter:

metafunc (Metafunc) – Der Metafunc-Helfer für die Testfunktion.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für eine gegebene Funktionsdefinition werden nur conftest-Dateien im Verzeichnis der Funktion und ihren übergeordneten Verzeichnissen abgefragt.

pytest_make_parametrize_id(config, val, argname)

Gibt eine benutzerfreundliche String-Darstellung des gegebenen val zurück, die von @pytest.mark.parametrize-Aufrufen verwendet wird, oder None, wenn der Hook val nicht kennt.

Der Parametername ist als argname verfügbar, falls erforderlich.

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis.

Parameter:

• config (Config) – Das Pytest-Konfigurationsobjekt.

• val (object) – Der parametrisierte Wert.

• argname (str) – Der automatische Parametername, der von Pytest generiert wird.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren.

Hooks zur Beeinflussung des Test-Skippings

pytest_markeval_namespace(config)

Wird beim Erstellen des Globals-Dictionary aufgerufen, das zur Auswertung von String-Bedingungen in xfail/skipif-Markern verwendet wird.

Dies ist nützlich, wenn die Bedingung für einen Marker Objekte erfordert, deren Beschaffung während der Sammelzeit teuer oder unmöglich ist, was für normale boolesche Bedingungen erforderlich ist.

Hinzugefügt in Version 6.2.

Parameter:

config (Config) – Das Pytest-Konfigurationsobjekt.

Gibt zurück:

Ein Wörterbuch mit zusätzlichen globalen Variablen, die hinzugefügt werden sollen.

Rückgabetyp:

dict[str, Any]

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für jedes Element werden nur conftest-Dateien in den übergeordneten Verzeichnissen des Elements abgefragt.

Nachdem die Sammlung abgeschlossen ist, können Sie die Reihenfolge der Elemente ändern, die Testelemente löschen oder anderweitig ändern

pytest_collection_modifyitems(session, config, items)

Wird aufgerufen, nachdem die Sammlung durchgeführt wurde. Kann die Elemente filtern oder ihre Reihenfolge ändern.

Wenn Elemente abgewählt werden (aus items herausgefiltert), muss der Hook pytest_deselected explizit mit den abgewählten Elementen aufgerufen werden, um andere Plugins ordnungsgemäß zu benachrichtigen, z. B. mit config.hook.pytest_deselected(items=deselected_items).

Parameter:

• session (Session) – Das Pytest-Sitzungsobjekt.

• config (Config) – Das Pytest-Konfigurationsobjekt.

• items (Liste[Item]) – Liste von Item-Objekten.

Verwendung in conftest-Plugins

Jedes conftest-Plugin kann diesen Hook implementieren.

Hinweis

Wenn dieser Hook in conftest.py-Dateien implementiert ist, empfängt er immer alle gesammelten Items, nicht nur die unter dem conftest.py, in dem er implementiert ist.

pytest_collection_finish(session)

Wird aufgerufen, nachdem die Sammlung durchgeführt und modifiziert wurde.

Parameter:

session (Session) – Das Pytest-Sitzungsobjekt.

Verwendung in conftest-Plugins

Jedes conftest-Plugin kann diesen Hook implementieren.

Hooks für die Testausführung (runtest)

Alle runtest-bezogenen Hooks erhalten ein pytest.Item-Objekt.

pytest_runtestloop(session)

Führt die Hauptschleife der Testausführung durch (nachdem die Sammlung abgeschlossen ist).

Die Standard-Hook-Implementierung führt das runtest-Protokoll für alle in der Sitzung gesammelten Items aus (session.items), es sei denn, die Sammlung ist fehlgeschlagen oder die Pytest-Option collectonly ist gesetzt.

Wenn zu irgendeinem Zeitpunkt pytest.exit() aufgerufen wird, wird die Schleife sofort beendet.

Wenn zu irgendeinem Zeitpunkt session.shouldfail oder session.shouldstop gesetzt sind, wird die Schleife nach Abschluss des runtest-Protokolls für das aktuelle Item beendet.

Parameter:

session (Session) – Das Pytest-Sitzungsobjekt.

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis. Der Rückgabewert wird nicht verwendet, stoppt aber nur die weitere Verarbeitung.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren.

pytest_runtest_protocol(item, nextitem)

Führt das runtest-Protokoll für ein einzelnes Test-Item aus.

Das Standard-Runtest-Protokoll ist wie folgt (siehe einzelne Hooks für vollständige Details)

• pytest_runtest_logstart(nodeid, location)

• Einrichtungsphase

  • call = pytest_runtest_setup(item) (eingewickelt in CallInfo(when="setup"))

  • report = pytest_runtest_makereport(item, call)

  • pytest_runtest_logreport(report)

  • pytest_exception_interact(call, report) bei einer interaktiven Ausnahme

• Aufrufsphase, wenn die Einrichtung erfolgreich war und die Pytest-Option setuponly nicht gesetzt ist

  • call = pytest_runtest_call(item) (eingewickelt in CallInfo(when="call"))

  • report = pytest_runtest_makereport(item, call)

  • pytest_runtest_logreport(report)

  • pytest_exception_interact(call, report) bei einer interaktiven Ausnahme

• Aufräumphase

  • call = pytest_runtest_teardown(item, nextitem) (eingewickelt in CallInfo(when="teardown"))

  • report = pytest_runtest_makereport(item, call)

  • pytest_runtest_logreport(report)

  • pytest_exception_interact(call, report) bei einer interaktiven Ausnahme

• pytest_runtest_logfinish(nodeid, location)

Parameter:

• item (Item) – Test-Item, für das das Runtest-Protokoll ausgeführt wird.

• nextitem (Item | None) – Das als Nächstes geplante Test-Item (oder None, wenn dies das Ende ist, mein Freund).

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis. Der Rückgabewert wird nicht verwendet, stoppt aber nur die weitere Verarbeitung.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren.

pytest_runtest_logstart(nodeid, location)

Wird zu Beginn der Ausführung des Runtest-Protokolls für ein einzelnes Item aufgerufen.

Siehe pytest_runtest_protocol für eine Beschreibung des Runtest-Protokolls.

Parameter:

• nodeid (str) – Vollständige Node-ID des Items.

• location (Tupel[str, int | None, str]) – Ein Tupel aus (filename, lineno, testname), wobei filename ein Dateipfad relativ zu config.rootpath ist und lineno 0-basiert ist.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für ein gegebenes Item werden nur conftest-Dateien im Verzeichnis des Items und seinen übergeordneten Verzeichnissen berücksichtigt.

pytest_runtest_logfinish(nodeid, location)

Wird am Ende der Ausführung des Runtest-Protokolls für ein einzelnes Item aufgerufen.

Siehe pytest_runtest_protocol für eine Beschreibung des Runtest-Protokolls.

Parameter:

• nodeid (str) – Vollständige Node-ID des Items.

• location (Tupel[str, int | None, str]) – Ein Tupel aus (filename, lineno, testname), wobei filename ein Dateipfad relativ zu config.rootpath ist und lineno 0-basiert ist.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für ein gegebenes Item werden nur conftest-Dateien im Verzeichnis des Items und seinen übergeordneten Verzeichnissen berücksichtigt.

pytest_runtest_setup(item)

Wird aufgerufen, um die Einrichtungsphase für ein Test-Item durchzuführen.

Die Standardimplementierung führt setup() auf item und allen seinen Eltern (die noch nicht eingerichtet wurden) aus. Dies beinhaltet das Abrufen der Werte von Fixtures, die vom Item benötigt werden (die noch nicht abgerufen wurden).

Parameter:

item (Item) – Das Item.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für ein gegebenes Item werden nur conftest-Dateien im Verzeichnis des Items und seinen übergeordneten Verzeichnissen berücksichtigt.

pytest_runtest_call(item)

Wird aufgerufen, um den Test für ein Test-Item auszuführen (die Aufrufsphase).

Die Standardimplementierung ruft item.runtest() auf.

Parameter:

item (Item) – Das Item.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für ein gegebenes Item werden nur conftest-Dateien im Verzeichnis des Items und seinen übergeordneten Verzeichnissen berücksichtigt.

pytest_runtest_teardown(item, nextitem)

Wird aufgerufen, um die Aufräumphase für ein Test-Item durchzuführen.

Die Standardimplementierung führt die Finalisierer aus und ruft teardown() auf item und allen seinen Eltern (die aufgeräumt werden müssen) auf. Dies beinhaltet die Ausführung der Aufräumphase von Fixtures, die vom Item benötigt werden (wenn sie außer Reichweite geraten).

Parameter:

• item (Item) – Das Item.

• nextitem (Item | None) – Das als Nächstes geplante Test-Item (None, wenn kein weiteres Test-Item geplant ist). Dieses Argument wird verwendet, um exakte Aufräumarbeiten durchzuführen, d.h. gerade genug Finalisierer aufzurufen, damit nextitem nur Setup-Funktionen aufrufen muss.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für ein gegebenes Item werden nur conftest-Dateien im Verzeichnis des Items und seinen übergeordneten Verzeichnissen berücksichtigt.

pytest_runtest_makereport(item, call)

Wird aufgerufen, um für jede der Setup-, Call- und Teardown-Runtest-Phasen eines Test-Items einen TestReport zu erstellen.

Siehe pytest_runtest_protocol für eine Beschreibung des Runtest-Protokolls.

Parameter:

• item (Item) – Das Item.

• call (CallInfo[None]) – Die CallInfo für die Phase.

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für ein gegebenes Item werden nur conftest-Dateien im Verzeichnis des Items und seinen übergeordneten Verzeichnissen berücksichtigt.

Für ein tieferes Verständnis können Sie die Standardimplementierung dieser Hooks in _pytest.runner und möglicherweise auch in _pytest.pdb betrachten, das mit _pytest.capture und dessen Ein-/Ausgabe-Erfassung interagiert, um bei einem Testfehler sofort in den interaktiven Debugging-Modus zu wechseln.

pytest_pyfunc_call(pyfuncitem)

Ruft die zugrunde liegende Testfunktion auf.

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis.

Parameter:

pyfuncitem (Function) – Das Funktions-Item.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für ein gegebenes Item werden nur conftest-Dateien im Verzeichnis des Items und seinen übergeordneten Verzeichnissen berücksichtigt.

Hooks für die Berichterstattung

Sitzungsbezogene Berichterstattungs-Hooks

pytest_collectstart(collector)

Collector beginnt mit dem Sammeln.

Parameter:

collector (Collector) – Der Collector.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für einen gegebenen Sammler werden nur conftest-Dateien im Verzeichnis des Sammlers und seinen übergeordneten Verzeichnissen abgefragt.

pytest_make_collect_report(collector)

Führt collector.collect() aus und gibt einen CollectReport zurück.

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis.

Parameter:

collector (Collector) – Der Collector.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für einen gegebenen Sammler werden nur conftest-Dateien im Verzeichnis des Sammlers und seinen übergeordneten Verzeichnissen abgefragt.

pytest_itemcollected(item)

Wir haben gerade ein Test-Item gesammelt.

Parameter:

item (Item) – Das Item.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für ein gegebenes Item werden nur conftest-Dateien im Verzeichnis des Items und seinen übergeordneten Verzeichnissen berücksichtigt.

pytest_collectreport(report)

Collector hat die Sammlung abgeschlossen.

Parameter:

report (CollectReport) – Der Sammelbericht.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für einen gegebenen Sammler werden nur conftest-Dateien im Verzeichnis des Sammlers und seinen übergeordneten Verzeichnissen abgefragt.

pytest_deselected(items)

Wird für abgewählte Test-Items aufgerufen, z.B. nach Schlüsselwort.

Beachten Sie, dass dieser Hook zwei Integrationsaspekte für Plugins hat

• er kann *implementiert* werden, um über abgewählte Items benachrichtigt zu werden

• er muss von Implementierungen von pytest_collection_modifyitems *aufgerufen* werden, wenn Items abgewählt werden (um andere Plugins ordnungsgemäß zu benachrichtigen).

Kann mehrmals aufgerufen werden.

Parameter:

items (Sequenz[Item]) – Die Items.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren.

pytest_report_header(config, start_path, startdir)

Gibt eine Zeichenkette oder eine Liste von Zeichenketten zurück, die als Kopfzeileninformationen für die Terminalberichterstattung angezeigt werden sollen.

Parameter:

• config (Config) – Das Pytest-Konfigurationsobjekt.

• start_path (pathlib.Path) – Das Startverzeichnis.

• startdir (LEGACY_PATH) – Das Startverzeichnis (veraltet).

Hinweis

Zeilen, die von einem Plugin zurückgegeben werden, werden vor denen von Plugins angezeigt, die davor ausgeführt wurden. Wenn Ihre Zeile(n) zuerst angezeigt werden sollen, verwenden Sie trylast=True.

Geändert in Version 7.0.0: Der Parameter start_path wurde als pathlib.Path-Äquivalent des Parameters startdir hinzugefügt. Der Parameter startdir wurde als veraltet markiert.

Verwendung in conftest-Plugins

Dieser Hook wird nur für initiale conftests aufgerufen.

pytest_report_collectionfinish(config, start_path, startdir, items)

Gibt eine Zeichenkette oder eine Liste von Zeichenketten zurück, die nach erfolgreichem Abschluss der Sammlung angezeigt werden sollen.

Diese Zeichenketten werden nach der Standardmeldung "collected X items" angezeigt.

Hinzugefügt in Version 3.2.

Parameter:

• config (Config) – Das Pytest-Konfigurationsobjekt.

• start_path (pathlib.Path) – Das Startverzeichnis.

• startdir (LEGACY_PATH) – Das Startverzeichnis (veraltet).

• items (Sequenz[Item]) – Liste der Pytest-Items, die ausgeführt werden sollen; diese Liste sollte nicht geändert werden.

Hinweis

Zeilen, die von einem Plugin zurückgegeben werden, werden vor denen von Plugins angezeigt, die davor ausgeführt wurden. Wenn Ihre Zeile(n) zuerst angezeigt werden sollen, verwenden Sie trylast=True.

Geändert in Version 7.0.0: Der Parameter start_path wurde als pathlib.Path-Äquivalent des Parameters startdir hinzugefügt. Der Parameter startdir wurde als veraltet markiert.

Verwendung in conftest-Plugins

Jedes conftest-Plugin kann diesen Hook implementieren.

pytest_report_teststatus(report, config)

Gibt die Ergebnis-Kategorie, den Kurzbuchstaben und das ausführliche Wort für die Statusberichterstattung zurück.

Die Ergebnis-Kategorie ist eine Kategorie, in der das Ergebnis gezählt wird, z.B. "passed", "skipped", "error" oder die leere Zeichenkette.

Der Kurzbuchstabe wird während des Testfortschritts angezeigt, z.B. ".", "s", "E" oder die leere Zeichenkette.

Das ausführliche Wort wird während des Testfortschritts im ausführlichen Modus angezeigt, z.B. "PASSED", "SKIPPED", "ERROR" oder die leere Zeichenkette.

Pytest kann diese implizit entsprechend dem Testergebnis formatieren. Um eine explizite Formatierung bereitzustellen, geben Sie ein Tupel für das ausführliche Wort zurück, z.B. "rerun", "R", ("RERUN", {"yellow": True}).

Parameter:

• report (CollectReport | TestReport) – Das Berichtsobjekt, dessen Status zurückgegeben werden soll.

• config (Config) – Das Pytest-Konfigurationsobjekt.

Gibt zurück:

Der Teststatus.

Rückgabetyp:

TestShortLogReport | Tupel[str, str, str | Tupel[str, Mapping[str, bool]]]

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis.

Verwendung in conftest-Plugins

Jedes conftest-Plugin kann diesen Hook implementieren.

pytest_report_to_serializable(config, report)

Serialisiert das gegebene Berichtsobjekt in eine Datenstruktur, die sich zum Senden über das Netzwerk eignet, z.B. konvertiert in JSON.

Parameter:

• config (Config) – Das Pytest-Konfigurationsobjekt.

• report (CollectReport | TestReport) – Der Bericht.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Die genauen Details können vom Plugin abhängen, das den Hook aufruft.

pytest_report_from_serializable(config, data)

Stellt ein Berichtsobjekt wieder her, das zuvor mit pytest_report_to_serializable serialisiert wurde.

Parameter:

config (Config) – Das Pytest-Konfigurationsobjekt.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Die genauen Details können vom Plugin abhängen, das den Hook aufruft.

pytest_terminal_summary(terminalreporter, exitstatus, config)

Fügt einen Abschnitt zur Terminal-Zusammenfassungsberichterstattung hinzu.

Parameter:

• terminalreporter (TerminalReporter) – Das interne Terminal-Reporter-Objekt.

• exitstatus (ExitCode) – Der Exit-Status, der an das Betriebssystem zurückgemeldet wird.

• config (Config) – Das Pytest-Konfigurationsobjekt.

Hinzugefügt in Version 4.2: Der Parameter config.

Verwendung in conftest-Plugins

Jedes conftest-Plugin kann diesen Hook implementieren.

pytest_fixture_setup(fixturedef, request)

Führt die Ausführung der Fixture-Einrichtung durch.

Parameter:

• fixturedef (FixtureDef[Any]) – Das Fixture-Definitions-Objekt.

• request (SubRequest) – Das Fixture-Anfrageobjekt.

Gibt zurück:

Der Rückgabewert des Aufrufs der Fixture-Funktion.

Rückgabetyp:

object | None

Stoppt beim ersten Nicht-None-Ergebnis, siehe firstresult: Stoppen beim ersten Nicht-None-Ergebnis.

Hinweis

Wenn die Fixture-Funktion None zurückgibt, werden andere Implementierungen dieser Hook-Funktion weiterhin aufgerufen, gemäß dem Verhalten der Option firstresult: Stoppen beim ersten Nicht-None-Ergebnis.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für ein gegebenes Fixture werden nur conftest-Dateien im Verzeichnis des Fixture-Scopes und seinen übergeordneten Verzeichnissen berücksichtigt.

pytest_fixture_post_finalizer(fixturedef, request)

Wird nach dem Aufräumen des Fixtures aufgerufen, aber bevor der Cache gelöscht wird, sodass das Fixture-Ergebnis fixturedef.cached_result noch verfügbar ist (nicht None).

Parameter:

• fixturedef (FixtureDef[Any]) – Das Fixture-Definitions-Objekt.

• request (SubRequest) – Das Fixture-Anfrageobjekt.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für ein gegebenes Fixture werden nur conftest-Dateien im Verzeichnis des Fixture-Scopes und seinen übergeordneten Verzeichnissen berücksichtigt.

pytest_warning_recorded(warning_message, when, nodeid, location)

Verarbeitet eine Warnung, die vom internen Pytest-Warnungs-Plugin erfasst wurde.

Parameter:

• warning_message (warnings.WarningMessage) – Die erfasste Warnung. Dies ist das gleiche Objekt, das von warnings.catch_warnings erzeugt wird und dieselben Attribute wie die Parameter von warnings.showwarning() enthält.

• when (Literal['config', 'collect', 'runtest']) –

  Gibt an, wann die Warnung erfasst wurde. Mögliche Werte

  • "config": während der Konfigurations-/Initialisierungsphase von pytest.

  • "collect": während der Testsammlung.

  • "runtest": während der Testausführung.

• nodeid (str) – Vollständige ID des Items. Leere Zeichenkette für Warnungen, die nicht zu einem bestimmten Knoten gehören.

• location (Tupel[str, int, str] | None) – Wenn verfügbar, enthält Informationen über den Ausführungskontext der erfassten Warnung (Dateiname, Zeilennummer, Funktion). function wird zu <module> ausgewertet, wenn der Ausführungskontext auf Modulebene liegt.

Hinzugefügt in Version 6.0.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Wenn die Warnung spezifisch für einen bestimmten Knoten ist, werden nur conftest-Dateien in den übergeordneten Verzeichnissen des Knotens berücksichtigt.

Zentraler Hook für die Berichterstattung über die Testausführung

pytest_runtest_logreport(report)

Verarbeitet den TestReport, der für jede der Setup-, Call- und Teardown-Runtest-Phasen eines Items erstellt wird.

Siehe pytest_runtest_protocol für eine Beschreibung des Runtest-Protokolls.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für ein gegebenes Item werden nur conftest-Dateien im Verzeichnis des Items und seinen übergeordneten Verzeichnissen berücksichtigt.

Hooks für Assertions

pytest_assertrepr_compare(config, op, left, right)

Gibt eine Erklärung für Vergleiche in fehlgeschlagenen Assertions-Ausdrücken zurück.

Gibt None für keine benutzerdefinierte Erklärung zurück, andernfalls eine Liste von Zeichenketten. Die Zeichenketten werden mit Zeilenumbrüchen verbunden, aber alle Zeilenumbrüche *innerhalb* einer Zeichenkette werden maskiert. Beachten Sie, dass alle Zeilen außer der ersten leicht eingerückt werden; die Absicht ist, dass die erste Zeile eine Zusammenfassung ist.

Parameter:

• config (Config) – Das Pytest-Konfigurationsobjekt.

• op (str) – Der Operator, z.B. "==", "!=", "not in".

• left (object) – Der linke Operand.

• right (object) – Der rechte Operand.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für ein gegebenes Item werden nur conftest-Dateien im Verzeichnis des Items und seinen übergeordneten Verzeichnissen berücksichtigt.

pytest_assertion_pass(item, lineno, orig, expl)

Wird jedes Mal aufgerufen, wenn eine Assertion erfolgreich ist.

Hinzugefügt in Version 5.0.

Verwenden Sie diesen Hook, um nach einer erfolgreichen Assertion eine Verarbeitung durchzuführen. Die ursprünglichen Assertionsinformationen sind im String orig verfügbar, und die von Pytest introspektierten Assertionsinformationen sind im String expl verfügbar.

Dieser Hook muss explizit über die Konfigurationsoption enable_assertion_pass_hook aktiviert werden

toml

[pytest]
enable_assertion_pass_hook = true

ini

[pytest]
enable_assertion_pass_hook = true

Sie müssen die .pyc-Dateien in Ihrem Projektverzeichnis und den Interpreterbibliotheken **bereinigen**, wenn Sie diese Option aktivieren, da Assertions neu geschrieben werden müssen.

Parameter:

• item (Item) – Pytest-Item-Objekt des aktuellen Tests.

• lineno (int) – Zeilennummer der Assertionsanweisung.

• orig (str) – Zeichenkette mit der ursprünglichen Assertion.

• expl (str) – Zeichenkette mit der Assertionserklärung.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für ein gegebenes Item werden nur conftest-Dateien im Verzeichnis des Items und seinen übergeordneten Verzeichnissen berücksichtigt.

Hooks für Debugging/Interaktion

Es gibt einige Hooks, die für spezielle Berichterstattungen oder die Interaktion mit Ausnahmen verwendet werden können

pytest_internalerror(excrepr, excinfo)

Wird für interne Fehler aufgerufen.

Gibt True zurück, um die Fallback-Behandlung des direkten Druckens einer INTERNALERROR-Nachricht nach sys.stderr zu unterdrücken.

Parameter:

• excrepr (ExceptionRepr) – Das Ausnahme-Repräsentationsobjekt.

• excinfo (ExceptionInfo[BaseException]) – Die Ausnahminformationen.

Verwendung in conftest-Plugins

Jedes conftest-Plugin kann diesen Hook implementieren.

pytest_keyboard_interrupt(excinfo)

Wird bei einem Tastaturunterbrechung aufgerufen.

Parameter:

excinfo (ExceptionInfo[KeyboardInterrupt | Exit]) – Die Ausnahminformationen.

Verwendung in conftest-Plugins

Jedes conftest-Plugin kann diesen Hook implementieren.

pytest_exception_interact(node, call, report)

Wird aufgerufen, wenn eine Ausnahme ausgelöst wurde, die potenziell interaktiv behandelt werden kann.

Kann während der Sammlung aufgerufen werden (siehe pytest_make_collect_report), in diesem Fall ist report ein CollectReport.

Kann während des runtest eines Items aufgerufen werden (siehe pytest_runtest_protocol), in diesem Fall ist report ein TestReport.

Dieser Hook wird nicht aufgerufen, wenn die ausgelöste Ausnahme eine interne Ausnahme wie skip.Exception ist.

Parameter:

• node (Item | Collector) – Das Item oder der Collector.

• call (CallInfo[Any]) – Die Aufruf-Informationen. Enthält die Ausnahme.

• report (CollectReport | TestReport) – Der Sammlungs- oder Testbericht.

Verwendung in conftest-Plugins

Jede conftest-Datei kann diesen Hook implementieren. Für einen gegebenen Knoten werden nur conftest-Dateien in übergeordneten Verzeichnissen des Knotens konsultiert.

pytest_enter_pdb(config, pdb)

Wird bei pdb.set_trace() aufgerufen.

Kann von Plugins verwendet werden, um spezielle Aktionen durchzuführen, kurz bevor der Python-Debugger in den interaktiven Modus wechselt.

Parameter:

• config (Config) – Das Pytest-Konfigurationsobjekt.

• pdb (pdb.Pdb) – Die Pdb-Instanz.

Verwendung in conftest-Plugins

Jedes conftest-Plugin kann diesen Hook implementieren.

pytest_leave_pdb(config, pdb)

Wird beim Verlassen von pdb aufgerufen (z. B. mit continue nach pdb.set_trace()).

Kann von Plugins verwendet werden, um spezielle Aktionen durchzuführen, kurz nachdem der Python-Debugger den interaktiven Modus verlassen hat.

Parameter:

• config (Config) – Das Pytest-Konfigurationsobjekt.

• pdb (pdb.Pdb) – Die Pdb-Instanz.

Verwendung in conftest-Plugins

Jedes conftest-Plugin kann diesen Hook implementieren.

Collection-Baumobjekte

Dies sind die Collector- und Item-Klassen (zusammenfassend als "Knoten" bezeichnet), die den Collection-Baum bilden.

Node

class Node

Bases: ABC

Basisklasse von Collector und Item, den Komponenten des Test-Collection-Baums.

Collector sind die internen Knoten des Baums und Item sind die Blattknoten.

fspath: LEGACY_PATH

Eine LEGACY_PATH Kopie des path Attributs. Gedacht für die Verwendung in Methoden, die noch nicht auf pathlib.Path migriert wurden, wie z. B. Item.reportinfo. Wird in einer zukünftigen Version veraltet sein, bevorzugen Sie stattdessen die Verwendung von path.

name: str

Ein eindeutiger Name innerhalb des Gültigkeitsbereichs des übergeordneten Knotens.

parent

Der übergeordnete Collector-Knoten.

config: Config

Das pytest-Config-Objekt.

session: Session

Die pytest-Sitzung, zu der dieser Knoten gehört.

path: pathlib.Path

Dateisystempfad, von dem dieser Knoten gesammelt wurde (kann None sein).

keywords: MutableMapping[str, Any]

Schlüsselwörter/Markierungen, die aus allen Gültigkeitsbereichen gesammelt wurden.

own_markers: list[Mark]

Die Markierungsobjekte, die zu diesem Knoten gehören.

extra_keyword_matches: set[str]

Ermöglicht das Hinzufügen von zusätzlichen Schlüsselwörtern zum Abgleich.

stash: Stash

Ein Ort, an dem Plugins Informationen auf dem Knoten für ihre eigene Verwendung speichern können.

classmethod from_parent(parent, **kw)

Öffentlicher Konstruktor für Nodes.

Diese Indirektion wurde eingeführt, um die fragile Logik aus den Konstruktoren der Knoten zu entfernen.

Unterklassen können super().from_parent(...) verwenden, wenn sie die Konstruktion überschreiben.

Parameter:

parent (Node) – Der übergeordnete Knoten dieses Nodes.

property ihook: HookRelay

Fpath-sensibler Hook-Proxy, der zum Aufrufen von pytest-Hooks verwendet wird.

warn(warning)

Gibt eine Warnung für diesen Knoten aus.

Warnungen werden nach der Testsitzung angezeigt, es sei denn, sie werden explizit unterdrückt.

Parameter:

warning (Warning) – Die auszugebende Warnungsinstanz.

Löst aus:

ValueError – Wenn die warning Instanz keine Unterklasse von Warning ist.

Beispielanwendung

node.warn(PytestWarning("some message"))
node.warn(UserWarning("some message"))

Geändert in Version 6.2: Jede Unterklasse von Warning wird jetzt akzeptiert, anstatt nur Unterklassen von PytestWarning.

property nodeid: str

Ein ::-getrennter String, der seine Adresse im Collection-Baum angibt.

for ... in iter_parents()

Iteriert über alle übergeordneten Collector, beginnend bei und einschließlich sich selbst bis zur Wurzel des Collection-Baums.

Hinzugefügt in Version 8.1.

listchain()

Gibt eine Liste aller übergeordneten Collector zurück, beginnend von der Wurzel des Collection-Baums bis einschließlich sich selbst.

add_marker(marker, append=True)

Fügt dynamisch ein Markierungsobjekt zum Knoten hinzu.

Parameter:

• marker (str | MarkDecorator) – Die Markierung.

• append (bool) – Ob die Markierung angehängt oder vorangestellt werden soll.

iter_markers(name=None)

Iteriert über alle Markierungen des Knotens.

Parameter:

name (str | None) – Wenn angegeben, filtert die Ergebnisse nach dem Attributnamen.

Gibt zurück:

Ein Iterator der Markierungen des Knotens.

Rückgabetyp:

Iterator[Mark]

for ... in iter_markers_with_node(name=None)

Iteriert über alle Markierungen des Knotens.

Parameter:

name (str | None) – Wenn angegeben, filtert die Ergebnisse nach dem Attributnamen.

Gibt zurück:

Ein Iterator von (node, mark) Tupeln.

Rückgabetyp:

Iterator[tuple[Node, Mark]]

get_closest_marker(name: str) → Mark | None

get_closest_marker(name: str, default: Mark) → Mark

Gibt die erste Markierung zurück, die dem Namen entspricht, von der nächstgelegenen (z. B. Funktion) zur weiter entfernten Ebene (z. B. Modulebene).

Parameter:

• default – Rückgabewert, wenn keine Markierung gefunden wurde.

• name – Name, nach dem gefiltert werden soll.

listextrakeywords()

Gibt eine Menge aller zusätzlichen Schlüsselwörter in self und allen übergeordneten Elementen zurück.

addfinalizer(fin)

Registriert eine Funktion, die ohne Argumente aufgerufen wird, wenn dieser Knoten finalisiert wird.

Diese Methode kann nur aufgerufen werden, wenn dieser Knoten in einer Setup-Kette aktiv ist, z. B. während self.setup().

getparent(cls)

Holt den nächstgelegenen übergeordneten Knoten (einschließlich self), der eine Instanz der gegebenen Klasse ist.

Parameter:

cls (type[_NodeType]) – Die zu suchende Knotenklasse.

Gibt zurück:

Der Knoten, falls gefunden.

Rückgabetyp:

_NodeType | None

repr_failure(excinfo, style=None)

Gibt eine Darstellung eines Sammlungs- oder Testfehlers zurück.

Siehe auch

Arbeiten mit Nicht-Python-Tests

Parameter:

excinfo (ExceptionInfo[BaseException]) – Ausnahminformationen für den Fehler.

Collector

class Collector

Bases: Node, ABC

Basisklasse aller Collector.

Collector erstellen Kinder über collect() und bauen somit iterativ den Collection-Baum auf.

exception CollectError

Bases: Exception

Ein Fehler während der Sammlung, enthält eine benutzerdefinierte Nachricht.

abstractmethod collect()

Sammelt Kinder (Items und Collector) für diesen Collector.

repr_failure(excinfo)

Gibt eine Darstellung eines Sammlungsfehlers zurück.

Parameter:

excinfo (ExceptionInfo[BaseException]) – Ausnahminformationen für den Fehler.

config: Config

Das pytest-Config-Objekt.

name: str

Ein eindeutiger Name innerhalb des Gültigkeitsbereichs des übergeordneten Knotens.

parent

Der übergeordnete Collector-Knoten.

path: pathlib.Path

Dateisystempfad, von dem dieser Knoten gesammelt wurde (kann None sein).

session: Session

Die pytest-Sitzung, zu der dieser Knoten gehört.

Item

class Item

Bases: Node, ABC

Basisklasse aller Testaufrufe-Items.

Beachten Sie, dass für eine einzelne Funktion mehrere Testaufruf-Items vorhanden sein können.

user_properties: list[tuple[str, object]]

Eine Liste von Tupeln (Name, Wert), die benutzerdefinierte Eigenschaften für diesen Test enthält.

config: Config

Das pytest-Config-Objekt.

name: str

Ein eindeutiger Name innerhalb des Gültigkeitsbereichs des übergeordneten Knotens.

parent

Der übergeordnete Collector-Knoten.

path: pathlib.Path

Dateisystempfad, von dem dieser Knoten gesammelt wurde (kann None sein).

session: Session

Die pytest-Sitzung, zu der dieser Knoten gehört.

abstractmethod runtest()

Führt den Testfall für dieses Item aus.

Muss von Unterklassen implementiert werden.

Siehe auch

Arbeiten mit Nicht-Python-Tests

add_report_section(when, key, content)

Fügt einen neuen Berichtabschnitt hinzu, ähnlich wie intern für die Erfassung von stdout und stderr.

item.add_report_section("call", "stdout", "report section contents")

Parameter:

• when (str) – Einer der möglichen Erfassungszustände, "setup", "call", "teardown".

• key (str) – Name des Abschnitts, kann nach Belieben angepasst werden. Pytest verwendet intern "stdout" und "stderr".

• content (str) – Der vollständige Inhalt als String.

reportinfo()

Holt Standortinformationen für dieses Item für Testberichte.

Gibt ein Tupel mit drei Elementen zurück

• Der Pfad des Tests (Standard ist self.path)

• Die 0-basierte Zeilennummer des Tests (Standard ist None)

• Ein Name des Tests, der angezeigt werden soll (Standard ist "")

Siehe auch

Arbeiten mit Nicht-Python-Tests

Eigenschaft location: tuple[str, int | None, str]

Gibt ein Tupel von (relfspath, lineno, testname) für dieses Element zurück, wobei relfspath der Dateipfad relativ zu config.rootpath ist und lineno eine 0-basierte Zeilennummer ist.

Datei

Klasse File

Basen: FSCollector, ABC

Basisklasse für das Sammeln von Tests aus einer Datei.

Arbeiten mit Nicht-Python-Tests.

config: Config

Das pytest-Config-Objekt.

name: str

Ein eindeutiger Name innerhalb des Gültigkeitsbereichs des übergeordneten Knotens.

parent

Der übergeordnete Collector-Knoten.

path: pathlib.Path

Dateisystempfad, von dem dieser Knoten gesammelt wurde (kann None sein).

session: Session

Die pytest-Sitzung, zu der dieser Knoten gehört.

FSCollector

Klasse FSCollector

Basen: Collector, ABC

Basisklasse für Dateisystem-Kollektoren.

path: pathlib.Path

Dateisystempfad, von dem dieser Knoten gesammelt wurde (kann None sein).

Klassenmethode from_parent(parent, *, fspath=None, path=None, **kw)

Der öffentliche Konstruktor.

config: Config

Das pytest-Config-Objekt.

name: str

Ein eindeutiger Name innerhalb des Gültigkeitsbereichs des übergeordneten Knotens.

parent

Der übergeordnete Collector-Knoten.

session: Session

Die pytest-Sitzung, zu der dieser Knoten gehört.

Sitzung

final Klasse Session

Basen: Collector

Die Wurzel des Sammlungbaums.

Session sammelt die anfänglichen Pfade, die als Argumente an pytest übergeben werden.

Ausnahme Interrupted

Basen: KeyboardInterrupt

Signalisiert, dass der Testlauf unterbrochen wurde.

Ausnahme Failed

Bases: Exception

Signalisiert einen Stopp als fehlgeschlagener Testlauf.

Eigenschaft startpath: Path

Der Pfad, von dem aus pytest aufgerufen wurde.

Hinzugefügt in Version 7.0.0.

isinitpath(path, *, with_parents=False)

Ist Pfad ein anfänglicher Pfad?

Ein anfänglicher Pfad ist ein Pfad, der explizit an pytest auf der Kommandozeile übergeben wurde.

Parameter:

with_parents (bool) – Wenn gesetzt, gib auch True zurück, wenn der Pfad ein Elternteil eines anfänglichen Pfads ist.

Geändert in Version 8.0: Der Parameter with_parents wurde hinzugefügt.

perform_collect(args: Sequence[str] | None = None, genitems: Literal[True] = True) → Sequence[Item]

perform_collect(args: Sequence[str] | None = None, genitems: bool = True) → Sequence[Item | Collector]

Führt die Sammelphase für diese Sitzung durch.

Dies wird von der Standardimplementierung des Hooks pytest_collection aufgerufen; siehe die Dokumentation dieses Hooks für weitere Details. Zu Testzwecken kann es auch direkt auf einer frischen Session aufgerufen werden.

Diese Funktion erweitert normalerweise rekursiv alle von der Sitzung gesammelten Kollektoren zu ihren Elementen, und es werden nur Elemente zurückgegeben. Zu Testzwecken kann dies unterdrückt werden, indem genitems=False übergeben wird, in diesem Fall enthält der Rückgabewert diese Kollektoren unvergrößert, und session.items ist leer.

für ... in collect()

Sammelt Kinder (Items und Collector) für diesen Collector.

config: Config

Das pytest-Config-Objekt.

name: str

Ein eindeutiger Name innerhalb des Gültigkeitsbereichs des übergeordneten Knotens.

parent

Der übergeordnete Collector-Knoten.

path: pathlib.Path

Dateisystempfad, von dem dieser Knoten gesammelt wurde (kann None sein).

session: Session

Die pytest-Sitzung, zu der dieser Knoten gehört.

Paket

Klasse Package

Basen: Directory

Kollektor für Dateien und Verzeichnisse in einem Python-Paket – Verzeichnisse mit einer __init__.py-Datei.

Hinweis

Verzeichnisse ohne __init__.py-Datei werden stattdessen standardmäßig von Dir gesammelt. Beide sind Directory-Kollektoren.

Geändert in Version 8.0: Erbt nun von Directory.

für ... in collect()

Sammelt Kinder (Items und Collector) für diesen Collector.

config: Config

Das pytest-Config-Objekt.

name: str

Ein eindeutiger Name innerhalb des Gültigkeitsbereichs des übergeordneten Knotens.

parent

Der übergeordnete Collector-Knoten.

path: pathlib.Path

Dateisystempfad, von dem dieser Knoten gesammelt wurde (kann None sein).

session: Session

Die pytest-Sitzung, zu der dieser Knoten gehört.

Modul

Klasse Module

Basen: File, PyCollector

Kollektor für Testklassen und -funktionen in einem Python-Modul.

collect()

Sammelt Kinder (Items und Collector) für diesen Collector.

config: Config

Das pytest-Config-Objekt.

name: str

Ein eindeutiger Name innerhalb des Gültigkeitsbereichs des übergeordneten Knotens.

parent

Der übergeordnete Collector-Knoten.

path: pathlib.Path

Dateisystempfad, von dem dieser Knoten gesammelt wurde (kann None sein).

session: Session

Die pytest-Sitzung, zu der dieser Knoten gehört.

Klasse

Klasse Class

Basen: PyCollector

Kollektor für Testmethoden (und verschachtelte Klassen) in einer Python-Klasse.

Klassenmethode from_parent(parent, *, name, obj=None, **kw)

Der öffentliche Konstruktor.

collect()

Sammelt Kinder (Items und Collector) für diesen Collector.

config: Config

Das pytest-Config-Objekt.

name: str

Ein eindeutiger Name innerhalb des Gültigkeitsbereichs des übergeordneten Knotens.

parent

Der übergeordnete Collector-Knoten.

path: pathlib.Path

Dateisystempfad, von dem dieser Knoten gesammelt wurde (kann None sein).

session: Session

Die pytest-Sitzung, zu der dieser Knoten gehört.

Funktion

Klasse Function

Basen: PyobjMixin, Item

Element, das für die Einrichtung und Ausführung einer Python-Testfunktion zuständig ist.

Parameter:

• name – Der vollständige Funktionsname, einschließlich aller Dekorationen, wie sie durch Parametrisierung hinzugefügt werden (my_func[my_param]).

• parent – Das übergeordnete Node.

• config – Das pytest Config-Objekt.

• callspec – Wenn angegeben, wurde diese Funktion parametrisiert und callspec enthält Metainformationen über die Parametrisierung.

• callobj – Wenn angegeben, das Objekt, das aufgerufen wird, wenn die Funktion aufgerufen wird. Andernfalls wird callobj von parent unter Verwendung von originalname abgerufen.

• keywords – Schlüsselwörter, die an das Funktions-Objekt für die „-k“-Übereinstimmung gebunden sind.

• session – Das pytest Session-Objekt.

• fixtureinfo – Fixture-Informationen, die bereits auf diesem Fixture-Knoten aufgelöst wurden.

• originalname – Der Attributname, der zum Zugriff auf das zugrunde liegende Funktions-Objekt verwendet wird. Standardmäßig name. Setzen Sie dies, wenn der Name vom ursprünglichen Namen abweicht, z. B. wenn er Dekorationen wie die von der Parametrisierung hinzugefügten enthält (my_func[my_param]).

originalname

Ursprünglicher Funktionsname, ohne Dekorationen (z. B. fügt die Parametrisierung ein "[...]"-Suffix zu Funktionsnamen hinzu), der zum Zugriff auf das zugrunde liegende Funktions-Objekt von parent verwendet wird (falls callobj nicht explizit angegeben ist).

Hinzugefügt in Version 3.0.

Klassenmethode from_parent(parent, **kw)

Der öffentliche Konstruktor.

Eigenschaft function

Zugrunde liegendes Python-„Funktions“-Objekt.

Eigenschaft instance

Python-Instanzobjekt, an das die Funktion gebunden ist.

Gibt None zurück, wenn es sich nicht um eine Testmethode handelt, z. B. für eine eigenständige Testfunktion, eine Klasse oder ein Modul.

runtest()

Führt die zugrunde liegende Testfunktion aus.

repr_failure(excinfo)

Gibt eine Darstellung eines Sammlungs- oder Testfehlers zurück.

Siehe auch

Arbeiten mit Nicht-Python-Tests

Parameter:

excinfo (ExceptionInfo[BaseException]) – Ausnahminformationen für den Fehler.

config: Config

Das pytest-Config-Objekt.

name: str

Ein eindeutiger Name innerhalb des Gültigkeitsbereichs des übergeordneten Knotens.

parent

Der übergeordnete Collector-Knoten.

path: pathlib.Path

Dateisystempfad, von dem dieser Knoten gesammelt wurde (kann None sein).

session: Session

Die pytest-Sitzung, zu der dieser Knoten gehört.

Funktionsdefinition

Klasse FunctionDefinition

Basisklassen: Function

Diese Klasse ist eine provisorische Lösung, bis wir zu tatsächlichen Funktionsdefinitionsknoten übergehen und metafunc loswerden.

runtest()

Führt die zugrunde liegende Testfunktion aus.

config: Config

Das pytest-Config-Objekt.

name: str

Ein eindeutiger Name innerhalb des Gültigkeitsbereichs des übergeordneten Knotens.

parent

Der übergeordnete Collector-Knoten.

path: pathlib.Path

Dateisystempfad, von dem dieser Knoten gesammelt wurde (kann None sein).

session: Session

Die pytest-Sitzung, zu der dieser Knoten gehört.

setup()

Führt die zugrunde liegende Testfunktion aus.

Objekte

Zugreifbare Objekte aus Fixtures oder Hooks oder importierbar von pytest.

CallInfo

final class CallInfo

Ergebnis-/Ausnahmeinformationen eines Funktionsaufrufs.

excinfo: ExceptionInfo[BaseException] | None

Die abgefangene Ausnahme des Aufrufs, falls eine aufgetreten ist.

start: float

Die Systemzeit, zu der der Aufruf gestartet wurde, in Sekunden seit der Epoche.

stop: float

Die Systemzeit, zu der der Aufruf beendet wurde, in Sekunden seit der Epoche.

duration: float

Die Dauer des Aufrufs in Sekunden.

when: Literal['collect', 'setup', 'call', 'teardown']

Der Kontext des Aufrufs: „collect“, „setup“, „call“ oder „teardown“.

property result: TResult

Der Rückgabewert des Aufrufs, falls er nicht fehlschlug.

Kann nur zugegriffen werden, wenn excinfo None ist.

classmethod from_call(func, when, reraise=None)

Ruft func auf und verpackt das Ergebnis in ein CallInfo.

Parameter:

• func (Callable[[], _pytest.runner.TResult]) – Die aufzurufende Funktion. Wird ohne Argumente aufgerufen.

• when (Literal['collect', 'setup', 'call', 'teardown']) – Die Phase, in der die Funktion aufgerufen wird.

• reraise (type[BaseException] | tuple[type[BaseException], ...] | None) – Ausnahme oder Ausnahmen, die bei Auslösung durch die Funktion propagiert werden sollen, anstatt in CallInfo verpackt zu werden.

CollectReport

final class CollectReport

Basisklassen: BaseReport

Sammlungsberichtsobjekt.

Berichte können beliebige zusätzliche Attribute enthalten.

nodeid: str

Normalisierte Sammlungs-Knoten-ID.

outcome: Literal['passed', 'failed', 'skipped']

Test-Ergebnis, immer einer von „passed“, „failed“, „skipped“.

longrepr: None | ExceptionInfo[BaseException] | tuple[str, int, str] | str | TerminalRepr

None oder eine Fehlerdarstellung.

result

Die gesammelten Elemente und Sammlungsknoten.

sections: list[tuple[str, str]]

Tupel aus Zeichenketten (Überschrift, Inhalt) mit zusätzlichen Informationen für den Testbericht. Wird von pytest verwendet, um Text aus stdout, stderr und abgefangenen Protokollereignissen hinzuzufügen. Kann von anderen Plugins verwendet werden, um beliebige Informationen zu Berichten hinzuzufügen.

property caplog: str

Gibt aufgezeichnete Protokollzeilen zurück, wenn die Protokollaufzeichnung aktiviert ist.

Hinzugefügt in Version 3.5.

property capstderr: str

Gibt aufgezeichneten Text von stderr zurück, wenn die Aufzeichnung aktiviert ist.

Hinzugefügt in Version 3.0.

property capstdout: str

Gibt aufgezeichneten Text von stdout zurück, wenn die Aufzeichnung aktiviert ist.

Hinzugefügt in Version 3.0.

property count_towards_summary: bool

Experimentell Ob dieser Bericht bei den am Ende der Test-Sitzung angezeigten Summen gezählt werden soll: „1 passed, 1 failure, etc.“.

Hinweis

Diese Funktion wird als experimentell betrachtet, daher beachten Sie, dass sie auch in Patch-Releases Änderungen unterliegen kann.

property failed: bool

Ob das Ergebnis fehlgeschlagen ist.

property fspath: str

Der Pfadteil des berichteten Knotens als Zeichenkette.

property head_line: str | None

Experimentell Die Kopfzeile, die mit der longrepr-Ausgabe für diesen Bericht angezeigt wird, häufiger während der Traceback-Darstellung bei Fehlern.

________ Test.foo ________

Im obigen Beispiel ist die Kopfzeile „Test.foo“.

Hinweis

Diese Funktion wird als experimentell betrachtet, daher beachten Sie, dass sie auch in Patch-Releases Änderungen unterliegen kann.

property longreprtext: str

Schreibgeschütztes Property, das die vollständige String-Darstellung von longrepr zurückgibt.

Hinzugefügt in Version 3.0.

property passed: bool

Ob das Ergebnis erfolgreich war.

property skipped: bool

Ob das Ergebnis übersprungen wurde.

Config

final class Config

Zugriff auf Konfigurationswerte, Plugin-Manager und Plugin-Hooks.

Parameter:

• pluginmanager (PytestPluginManager) – Ein pytest PluginManager.

• invocation_params (InvocationParams) – Objekt, das Parameter bezüglich des pytest.main()-Aufrufs enthält.

final class InvocationParams(*, args, plugins, dir)

Enthält Parameter, die während pytest.main() übergeben wurden.

Die Objektattribute sind schreibgeschützt.

Hinzugefügt in Version 5.1.

Hinweis

Beachten Sie, dass die Umgebungsvariable PYTEST_ADDOPTS und die Konfigurationsoption addopts von pytest behandelt werden und nicht im Attribut args enthalten sind.

Plugins, die auf InvocationParams zugreifen, müssen sich dessen bewusst sein.

args: tuple[str, ...]

Die Kommandozeilenargumente, wie sie an pytest.main() übergeben wurden.

plugins: Sequence[str | object] | None

Zusätzliche Plugins, kann None sein.

dir: Path

Das Verzeichnis, von dem pytest.main() aufgerufen wurde.

class ArgsSource(*values)

Gibt die Quelle der Testargumente an.

Hinzugefügt in Version 7.2.

ARGS = 1

Kommandozeilenargumente.

INVOCATION_DIR = 2

Aufrufverzeichnis.

TESTPATHS = 3

Konfigurationswert ‚testpaths‘.

option

Zugriff auf Kommandozeilenoptionen als Attribute.

Typ:

argparse.Namespace

invocation_params

Die Parameter, mit denen pytest aufgerufen wurde.

Typ:

InvocationParams

pluginmanager

Der Plugin-Manager verwaltet die Plugin-Registrierung und den Hook-Aufruf.

Typ:

PytestPluginManager

stash

Ein Ort, an dem Plugins Informationen in der Konfiguration für ihre eigene Nutzung speichern können.

Typ:

Stash

property rootpath: Path

Der Pfad zum Root-Verzeichnis.

Hinzugefügt in Version 6.1.

property inipath: Path | None

Der Pfad zur Konfigurationsdatei.

Hinzugefügt in Version 6.1.

add_cleanup(func)

Fügt eine Funktion hinzu, die aufgerufen werden soll, wenn das Config-Objekt nicht mehr verwendet wird (normalerweise zeitgleich mit pytest_unconfigure).

classmethod fromdictargs(option_dict, args)

Konstruktor, der für Subprozesse verwendbar ist.

issue_config_time_warning(warning, stacklevel)

Gibt eine Warnung während der „configure“-Phase aus und behandelt sie.

Während pytest_configure können wir Warnungen nicht mit der Funktion catch_warnings_for_item abfangen, da es nicht möglich ist, Hook-Wrapper um pytest_configure zu haben.

Diese Funktion ist hauptsächlich für Plugins gedacht, die Warnungen während pytest_configure (oder ähnlichen Phasen) ausgeben müssen.

Parameter:

• warning (Warning) – Die Warninstanz.

• stacklevel (int) – stacklevel, der an warnings.warn weitergeleitet wird.

addinivalue_line(name, line)

Fügt eine Zeile zu einer Konfigurationsoption hinzu. Die Option muss deklariert worden sein, ist aber möglicherweise noch nicht gesetzt, in welchem Fall die Zeile zur ersten Zeile ihres Wertes wird.

getini(name)

Gibt den Konfigurationswert aus einer Konfigurationsdatei zurück.

Wenn ein Konfigurationswert nicht in einer Konfigurationsdatei definiert ist, wird der default-Wert, der bei der Registrierung der Konfiguration durch parser.addini bereitgestellt wurde, zurückgegeben. Bitte beachten Sie, dass Sie sogar None als gültigen Standardwert angeben können.

Wenn default bei der Registrierung über parser.addini nicht angegeben wird, wird ein Standardwert zurückgegeben, der auf dem an parser.addini übergebenen type-Parameter basiert. Die Standardwerte basierend auf type sind: paths, pathlist, args und linelist : leere Liste [] bool : False string : leere Zeichenkette "" int : 0 float : 0.0

Wenn weder der Parameter default noch der Parameter type bei der Registrierung der Konfiguration über parser.addini übergeben wird, wird die Konfiguration als Zeichenkette behandelt und eine leere Zeichenkette '' zurückgegeben.

Wenn der angegebene Name nicht durch einen vorherigen parser.addini-Aufruf (normalerweise von einem Plugin) registriert wurde, wird ein ValueError ausgelöst.

getoption(name, default=<NOTSET>, skip=False)

Gibt den Wert einer Kommandozeilenoption zurück.

Parameter:

• name (str) – Name der Option. Sie können auch den literalen --OPT-Option anstelle des „dest“-Optionsnamens angeben.

• default (Any) – Fallback-Wert, wenn keine Option dieses Namens über pytest_addoption deklariert wurde. Beachten Sie, dass dieser Parameter ignoriert wird, wenn die Option deklariert ist, auch wenn der Wert der Option None ist.

• skip (bool) – Wenn True, löst pytest.skip() aus, wenn die Option nicht deklariert ist oder einen None-Wert hat. Beachten Sie, dass selbst wenn True angegeben ist, ein angegebener Standardwert anstelle eines Sprungs zurückgegeben wird.

getvalue(name, path=None)

Veraltet, verwenden Sie stattdessen getoption().

getvalueorskip(name, path=None)

Veraltet, verwenden Sie stattdessen getoption(skip=True).

VERBOSITY_ASSERTIONS: Final = 'assertions'

Verbositäts-Typ für fehlgeschlagene Assertions (siehe verbosity_assertions).

VERBOSITY_TEST_CASES: Final = 'test_cases'

Verbositäts-Typ für die Ausführung von Testfällen (siehe verbosity_test_cases).

VERBOSITY_SUBTESTS: Final = 'subtests'

Verbositäts-Typ für fehlgeschlagene Subtests (siehe verbosity_subtests).

get_verbosity(verbosity_type=None)

Ruft die Verbositätsstufe für einen feingranularen Verbositäts-Typ ab.

Parameter:

verbosity_type (str | None) – Der Verbositäts-Typ, für den die Stufe abgerufen werden soll. Wenn für den angegebenen Typ eine Stufe konfiguriert ist, wird dieser Wert zurückgegeben. Wenn der angegebene Typ kein bekannter Verbositäts-Typ ist, wird die globale Verbositätsstufe zurückgegeben. Wenn der angegebene Typ None (Standard) ist, wird die globale Verbositätsstufe zurückgegeben.

Um eine Stufe für einen feingranularen Verbositäts-Typ zu konfigurieren, sollte die Konfigurationsdatei eine Einstellung für den Konfigurationsnamen und einen numerischen Wert für die Verbositätsstufe enthalten. Ein spezieller Wert „auto“ kann verwendet werden, um explizit die globale Verbositätsstufe zu verwenden.

Beispiel

toml

[tool.pytest]
verbosity_assertions = 2

ini

[pytest]
verbosity_assertions = 2

pytest -v

print(config.get_verbosity())  # 1
print(config.get_verbosity(Config.VERBOSITY_ASSERTIONS))  # 2

Verzeichnis

final class Dir

Sammler von Dateien in einem Dateisystemverzeichnis.

Hinzugefügt in Version 8.0.

Hinweis

Python-Verzeichnisse mit einer __init__.py-Datei werden stattdessen standardmäßig von Package gesammelt. Beide sind Directory-Sammler.

classmethod from_parent(parent, *, path)

Der öffentliche Konstruktor.

Parameter:

• parent (nodes.Collector) – Der übergeordnete Sammler dieses Verzeichnisses.

• path (pathlib.Path) – Der Pfad des Verzeichnisses.

for ... in collect()

Sammelt Kinder (Items und Collector) für diesen Collector.

config: Config

Das pytest-Config-Objekt.

name: str

Ein eindeutiger Name innerhalb des Gültigkeitsbereichs des übergeordneten Knotens.

parent

Der übergeordnete Collector-Knoten.

path: pathlib.Path

Dateisystempfad, von dem dieser Knoten gesammelt wurde (kann None sein).

session: Session

Die pytest-Sitzung, zu der dieser Knoten gehört.

Verzeichnis

class Directory

Basisklasse für das Sammeln von Dateien aus einem Verzeichnis.

Ein grundlegender Verzeichnissammler tut Folgendes: Er durchläuft die Dateien und Unterverzeichnisse im Verzeichnis und erstellt Sammler für sie, indem er die Hooks pytest_collect_directory und pytest_collect_file aufruft, nachdem geprüft wurde, ob sie mit pytest_ignore_collect ignoriert werden.

Die Standard-Verzeichnissammler sind Dir und Package.

Hinzugefügt in Version 8.0.

Verwendung eines benutzerdefinierten Verzeichnissammlers.

config: Config

Das pytest-Config-Objekt.

name: str

Ein eindeutiger Name innerhalb des Gültigkeitsbereichs des übergeordneten Knotens.

parent

Der übergeordnete Collector-Knoten.

path: pathlib.Path

Dateisystempfad, von dem dieser Knoten gesammelt wurde (kann None sein).

session: Session

Die pytest-Sitzung, zu der dieser Knoten gehört.

ExceptionInfo

final class ExceptionInfo

Umschließt sys.exc_info()-Objekte und bietet Hilfe zur Navigation des Tracebacks.

classmethod from_exception(exception, exprinfo=None)

Gibt eine ExceptionInfo für eine vorhandene Ausnahme zurück.

Die Ausnahme muss ein __traceback__-Attribut haben, das nicht None ist, andernfalls schlägt diese Funktion mit einem Assertionsfehler fehl. Das bedeutet, dass die Ausnahme ausgelöst worden sein muss oder ein Traceback mit der Methode with_traceback() hinzugefügt wurde.

Parameter:

exprinfo (str | None) – Eine Textzeichenkette, die hilft zu bestimmen, ob AssertionError aus der Ausgabe entfernt werden soll. Standardmäßig die Ausnahmemeldung/__str__().

Hinzugefügt in Version 7.4.

classmethod from_exc_info(exc_info, exprinfo=None)

Ähnlich wie from_exception(), aber unter Verwendung eines alten exc_info-Tupels.

classmethod from_current(exprinfo=None)

Gibt eine ExceptionInfo zurück, die dem aktuellen Traceback entspricht.

Warnung

Experimentelle API

Parameter:

exprinfo (str | None) – Eine Textzeichenkette, die hilft zu bestimmen, ob AssertionError aus der Ausgabe entfernt werden soll. Standardmäßig die Ausnahmemeldung/__str__().

classmethod for_later()

Gibt eine ungefüllte ExceptionInfo zurück.

fill_unfilled(exc_info)

Füllt eine ungefüllte ExceptionInfo, die mit for_later() erstellt wurde.

property type: type[E]

Die Ausnahmeklasse.

property value: E

Der Ausnahmewert.

property tb: TracebackType

Der rohe Traceback der Ausnahme.

property typename: str

Der Typname der Ausnahme.

property traceback: Traceback

Der Traceback.

exconly(tryshort=False)

Gibt die Ausnahme als Zeichenkette zurück.

Wenn „tryshort“ zu True ausgewertet wird und die Ausnahme eine AssertionError ist, wird nur der eigentliche Ausnahmeteil der Ausnahmedarstellung zurückgegeben (wodurch „AssertionError: “ vom Anfang entfernt wird).

errisinstance(exc)

Gibt True zurück, wenn die Ausnahme eine Instanz von exc ist.

Erwägen Sie stattdessen die Verwendung von isinstance(excinfo.value, exc).

getrepr(showlocals=False, style='long', abspath=False, tbfilter=True, funcargs=False, truncate_locals=True, truncate_args=True, chain=True)

Gibt die str()-fähige Darstellung dieser Ausnahmeinformationen zurück.

Parameter:

• showlocals (bool) – Zeigt lokale Variablen pro Traceback-Eintrag an. Wird ignoriert, wenn style=="native".

• style (str) – long|short|line|no|native|value Traceback-Stil.

• abspath (bool) – Ob Pfade zu absoluten Pfaden geändert oder unverändert gelassen werden sollen.

• tbfilter (bool | Callable[[ExceptionInfo[BaseException]], Traceback]) –

  Ein Filter für Traceback-Einträge.

  • Wenn falsch, werden keine Einträge versteckt.

  • Wenn wahr, werden interne Einträge und Einträge versteckt, die eine lokale Variable __tracebackhide__ = True enthalten.

  • Wenn ein Callable, wird das Filtern an das Callable delegiert.

  Wird ignoriert, wenn style "native" ist.

• funcargs (bool) – Zeigt Fixtures („funcargs“ aus historischen Gründen) pro Traceback-Eintrag an.

• truncate_locals (bool) – Wenn showlocals==True, stellen Sie sicher, dass lokale Variablen sicher als Zeichenketten dargestellt werden können.

• truncate_args (bool) – Wenn showargs==True, stellen Sie sicher, dass Argumente sicher als Zeichenketten dargestellt werden können.

• chain (bool) – Wenn verkettete Ausnahmen in Python 3 angezeigt werden sollen.

Geändert in Version 3.9: Parameter chain hinzugefügt.

match(regexp)

Prüft, ob der reguläre Ausdruck regexp mit der Zeichenkettenrepräsentation der Ausnahme übereinstimmt, indem re.search() verwendet wird.

Wenn sie übereinstimmt, wird True zurückgegeben, andernfalls wird ein AssertionError ausgelöst.

group_contains(expected_exception, *, match=None, depth=None)

Prüft, ob eine erfasste Ausnahmegruppe eine passende Ausnahme enthält.

Parameter:

• expected_exception (Type[BaseException] | Tuple[Type[BaseException]]) – Der erwartete Ausnahmetyp oder ein Tupel, wenn eine von mehreren möglichen Ausnahmetypen erwartet wird.

• match (str | re.Pattern[str] | None) –

  Wenn angegeben, eine Zeichenkette, die einen regulären Ausdruck enthält, oder ein reguläres Ausdrucksobjekt, das gegen die Zeichenkettenrepräsentation der Ausnahme und ihre __notes__ mit re.search() getestet wird.

  Um einen literalen String abzugleichen, der Sonderzeichen enthalten kann, kann das Muster zuerst mit re.escape() escaped werden.

• depth (Optional[int]) – Wenn None, wird nach einer passenden Ausnahme in jeder Verschachtelungstiefe gesucht. Wenn >= 1, wird nur eine Ausnahme abgeglichen, wenn sie sich auf der angegebenen Tiefe befindet (Tiefe = 1 sind die Ausnahmen, die in der obersten Ausnahmegruppe enthalten sind).

Hinzugefügt in Version 8.0.

Warnung

Diese Hilfsfunktion erleichtert die Überprüfung auf das Vorhandensein spezifischer Ausnahmen, ist jedoch sehr schlecht geeignet, um zu prüfen, ob die Gruppe *keine anderen Ausnahmen* enthält. Sie sollten stattdessen pytest.RaisesGroup in Betracht ziehen.

ExitCode

class ExitCode(*values)

Kodiert die gültigen Exit-Codes von pytest.

Derzeit können Benutzer und Plugins auch andere Exit-Codes angeben.

Hinzugefügt in Version 5.0.

FixtureDef

class FixtureDef

Bases: Generic[FixtureValue]

Ein Container für eine Fixture-Definition.

Hinweis: Derzeit gelten nur explizit dokumentierte Felder und Methoden als öffentliche stabile API.

property scope: Literal['session', 'package', 'module', 'class', 'function']

Scope-Zeichenkette, eine von "function", "class", "module", "package", "session".

execute(request)

Gibt den Wert dieser Fixture zurück und führt sie aus, wenn sie nicht gecacht ist.

MarkDecorator

class MarkDecorator

Ein Dekorator zum Anwenden einer Markierung auf Testfunktionen und -klassen.

MarkDecorator werden mit pytest.mark erstellt

mark1 = pytest.mark.NAME  # Simple MarkDecorator
mark2 = pytest.mark.NAME(name1=value)  # Parametrized MarkDecorator

und können dann als Decorators auf Testfunktionen angewendet werden.

@mark2
def test_function():
    pass

Wenn ein MarkDecorator aufgerufen wird, tut er Folgendes:

1. Wenn er mit einer einzelnen Klasse als einzigem positionalem Argument und ohne zusätzliche Keyword-Argumente aufgerufen wird, hängt er den Mark an die Klasse an, sodass er automatisch auf alle in dieser Klasse gefundenen Testfälle angewendet wird.

2. Wenn er mit einer einzelnen Funktion als einzigem positionalem Argument und ohne zusätzliche Keyword-Argumente aufgerufen wird, hängt er den Mark an die Funktion an, wobei alle Argumente, die bereits intern im MarkDecorator gespeichert sind, berücksichtigt werden.

3. Wenn er in einem anderen Fall aufgerufen wird, gibt er eine neue MarkDecorator-Instanz zurück, deren Inhalt mit den an diesen Aufruf übergebenen Argumenten aktualisiert wurde.

Hinweis: Die obigen Regeln verhindern, dass ein MarkDecorator nur eine einzelne Funktions- oder Klassenreferenz als posisitionales Argument ohne zusätzliche Schlüsselwort- oder positionale Argumente speichert. Dies können Sie umgehen, indem Sie with_args() verwenden.

property name: str

Alias für mark.name.

property args: tuple[Any, ...]

Alias für mark.args.

property kwargs: Mapping[str, Any]

Alias für mark.kwargs.

with_args(*args, **kwargs)

Gibt einen MarkDecorator mit zusätzlichen Argumenten zurück.

Im Gegensatz zum Aufruf des MarkDecorator kann with_args() auch dann verwendet werden, wenn das einzige Argument ein Callable/eine Klasse ist.

MarkGenerator

final class MarkGenerator

Factory für MarkDecorator Objekte - exponiert als Singleton-Instanz pytest.mark.

Beispiel

import pytest


@pytest.mark.slowtest
def test_function():
    pass

wendet einen 'slowtest'-Mark auf test_function an.

Mark

final class Mark

Ein pytest Mark.

name: str

Name des Mark.

args: tuple[Any, ...]

Positionale Argumente des Mark-Decorators.

kwargs: Mapping[str, Any]

Keyword-Argumente des Mark-Decorators.

combined_with(other)

Gibt einen neuen Mark zurück, der eine Kombination dieses Mark und eines anderen Mark ist.

Kombiniert durch Anhängen von Argumenten und Zusammenführen von Keyword-Argumenten.

Parameter:

other (Mark) – Der Mark, mit dem kombiniert werden soll.

Rückgabetyp:

Mark

Metafunc

final class Metafunc

Objekte, die an den pytest_generate_tests Hook übergeben werden.

Sie helfen bei der Inspektion einer Testfunktion und der Generierung von Tests gemäß der Testkonfiguration oder den Werten, die in der Klasse oder dem Modul, in dem eine Testfunktion definiert ist, angegeben sind.

definition

Zugriff auf die zugrunde liegende _pytest.python.FunctionDefinition.

config

Zugriff auf das pytest.Config Objekt für die Test-Session.

module

Das Modulobjekt, in dem die Testfunktion definiert ist.

function

Zugrunde liegende Python-Testfunktion.

fixturenames

Menge der von der Testfunktion benötigten Fixture-Namen.

cls

Klassenobjekt, in dem die Testfunktion definiert ist, oder None.

parametrize(argnames, argvalues, indirect=False, ids=None, scope=None, *, _param_mark=None)

Fügt neue Aufrufe zur zugrunde liegenden Testfunktion hinzu, indem die Liste von argvalues für die angegebenen argnames verwendet wird. Die Parametrisierung erfolgt während der Erfassungsphase. Wenn Sie teure Ressourcen einrichten müssen, informieren Sie sich über die Einstellung von indirect, um dies stattdessen während der Testeinrichtung zu tun.

Kann mehrmals pro Testfunktion aufgerufen werden (aber nur für verschiedene Argumentnamen), wobei jeder Aufruf alle vorherigen Parametrisierungen parametrisiert, z. B.

unparametrized:         t
parametrize ["x", "y"]: t[x], t[y]
parametrize [1, 2]:     t[x-1], t[x-2], t[y-1], t[y-2]

Parameter:

• argnames (str | Sequence[str]) – Eine kommagetrennte Zeichenkette, die ein oder mehrere Argumentnamen bezeichnet, oder eine Liste/ein Tupel von Argumentzeichenketten.

• argvalues (Iterable[ParameterSet | Sequence[object] | object]) –

  Die Liste der argvalues bestimmt, wie oft ein Test mit verschiedenen Argumentwerten aufgerufen wird.

  Wenn nur ein argname angegeben wurde, ist argvalues eine Liste von Werten. Wenn N argnames angegeben wurden, muss argvalues eine Liste von N-Tupeln sein, wobei jedes Tupel-Element einen Wert für seinen jeweiligen argname angibt.

• indirect (bool | Sequence[str]) – Eine Liste von Argumentnamen (Teilmenge von argnames) oder ein boolescher Wert. Wenn True, enthält die Liste alle Namen aus argnames. Jeder argvalue, der einem argname in dieser Liste entspricht, wird als request.param an seine jeweilige argname-Fixture-Funktion übergeben, damit diese während der Einrichtung eines Tests teurere Setups durchführen kann, anstatt zur Erfassungszeit.

• ids (Iterable[object | None] | Callable[[Any], object | None] | None) –

  Sequenz von (oder Generator für) IDs für argvalues, oder ein Callable, das einen Teil der ID für jeden argvalue zurückgibt.

  Bei Sequenzen (und Generatoren wie itertools.count()) sollten die zurückgegebenen IDs vom Typ string, int, float, bool oder None sein. Sie werden dem entsprechenden Index in argvalues zugeordnet. None bedeutet, die automatisch generierte ID zu verwenden.

  Hinzugefügt in Version 8.4: pytest.HIDDEN_PARAM bedeutet, den Parametersatz aus dem Testnamen zu verbergen. Kann höchstens 1 Mal verwendet werden, da Testnamen eindeutig sein müssen.

  Wenn es sich um ein Callable handelt, wird es für jeden Eintrag in argvalues aufgerufen, und der Rückgabewert wird als Teil der automatisch generierten ID für die gesamte Menge verwendet (wobei Teile mit Bindestrichen ("-") verbunden werden). Dies ist nützlich, um spezifischere IDs für bestimmte Elemente bereitzustellen, z. B. Daten. Die Rückgabe von None führt zu einer automatisch generierten ID.

  Wenn keine IDs angegeben werden, werden sie automatisch aus den argvalues generiert.

• scope (Literal['session', 'package', 'module', 'class', 'function'] | None) – Wenn angegeben, bezeichnet es den Geltungsbereich der Parameter. Der Geltungsbereich wird zur Gruppierung von Tests nach Parameterinstanzen verwendet. Er überschreibt auch jeden Fixture-Funktions-definierten Geltungsbereich und ermöglicht so die Einstellung eines dynamischen Geltungsbereichs unter Verwendung des Testkontexts oder der Konfiguration.

Parser

final class Parser

Parser für Kommandozeilenargumente und Konfigurationsdateiwerte.

Variablen:

extra_info – Ein Wörterbuch von generischen Parametern -> Wert, der angezeigt wird, wenn bei der Verarbeitung der Kommandozeilenargumente ein Fehler auftritt.

getgroup(name, description='', after=None)

Holt (oder erstellt) eine benannte Optionsgruppe.

Parameter:

• name (str) – Name der Optionsgruppe.

• description (str) – Lange Beschreibung für die Ausgabe von –help.

• after (str | None) – Name einer anderen Gruppe, wird zur Reihenfolge der Ausgabe von –help verwendet.

Gibt zurück:

Die Optionsgruppe.

Rückgabetyp:

OptionGroup

Das zurückgegebene Gruppenobjekt hat eine addoption-Methode mit derselben Signatur wie parser.addoption, wird aber in der jeweiligen Gruppe in der Ausgabe von pytest --help angezeigt.

addoption(*opts, **attrs)

Registriert eine Kommandozeilenoption.

Parameter:

• opts (str) – Optionsnamen, können kurze oder lange Optionen sein.

• attrs (Any) – Dieselben Attribute, die die Funktion add_argument() der argparse-Bibliothek akzeptiert.

Nach dem Parsen der Kommandozeile sind die Optionen über config.option.NAME im pytest-Konfigurationsobjekt verfügbar, wobei NAME normalerweise durch Übergabe eines dest-Attributs gesetzt wird, z. B. addoption("--long", dest="NAME", ...).

parse_known_args(args, namespace=None)

Die bekannten Argumente zu diesem Zeitpunkt parsen.

Gibt zurück:

Ein argparse Namespace-Objekt.

Rückgabetyp:

Namespace

parse_known_and_unknown_args(args, namespace=None)

Die bekannten Argumente zu diesem Zeitpunkt parsen und auch die verbleibenden unbekannten Flag-Argumente zurückgeben.

Gibt zurück:

Ein Tupel, das ein argparse Namespace-Objekt für die bekannten Argumente und eine Liste unbekannter Flag-Argumente enthält.

Rückgabetyp:

tuple[Namespace, list[str]]

addini(name, help, type=None, default=<notset>, *, aliases=())

Registriert eine Konfigurationsdateioption.

Parameter:

• name (str) – Name der Konfiguration.

• type (Literal['string', 'paths', 'pathlist', 'args', 'linelist', 'bool', 'int', 'float'] | None) –

  Typ der Konfiguration. Kann sein

  • string: eine Zeichenkette

  • bool: ein boolescher Wert

  • args: eine Liste von Zeichenketten, wie in einer Shell getrennt

  • linelist: eine Liste von Zeichenketten, getrennt durch Zeilenumbrüche

  • paths: eine Liste von pathlib.Path, getrennt wie in einer Shell

  • pathlist: eine Liste von py.path, getrennt wie in einer Shell

  • int: eine Ganzzahl

  • float: eine Gleitkommazahl

  Added in version 8.4: Die Typen float und int.

  Für die Typen paths und pathlist werden sie relativ zur Konfigurationsdatei betrachtet. Wenn die Ausführung ohne definierte Konfigurationsdatei erfolgt, werden sie relativ zum aktuellen Arbeitsverzeichnis betrachtet (z. B. mit --override-ini).

  Added in version 7.0: Der Variablentyp paths.

  Added in version 8.1: Verwendet das aktuelle Arbeitsverzeichnis, um paths und pathlist im Falle des Fehlens einer Konfigurationsdatei aufzulösen.

  Standardmäßig string, wenn None ist oder nicht übergeben wird.

• default (Any) – Standardwert, wenn keine Konfigurationsdateioption vorhanden ist, aber abgefragt wird.

• aliases (Sequence[str]) –

  Zusätzliche Namen, unter denen diese Option referenziert werden kann. Aliase lösen sich zum kanonischen Namen auf.

  Added in version 9.0: Der Parameter aliases.

Der Wert von Konfigurationsschlüsseln kann über einen Aufruf von config.getini(name) abgerufen werden.

OptionGroup

class OptionGroup

Eine Gruppe von Optionen, die in einem eigenen Abschnitt angezeigt wird.

addoption(*opts, **attrs)

Fügt dieser Gruppe eine Option hinzu.

Wenn eine gekürzte Version einer langen Option angegeben wird, wird sie in der Hilfe unterdrückt. addoption('--twowords', '--two-words') führt dazu, dass die Hilfe nur --two-words anzeigt, aber --twowords akzeptiert wird **und** das automatische Ziel in args.twowords liegt.

Parameter:

• opts (str) – Optionsnamen, können kurze oder lange Optionen sein.

• attrs (Any) – Dieselben Attribute, die die Funktion add_argument() der argparse-Bibliothek akzeptiert.

PytestPluginManager

final class PytestPluginManager

Bases: PluginManager

Ein pluggy.PluginManager mit zusätzlichen pytest-spezifischen Funktionen

• Laden von Plugins von der Kommandozeile, der Umgebungsvariable PYTEST_PLUGINS und globalen Variablen pytest_plugins, die in geladenen Plugins gefunden werden.

• conftest.py Laden beim Start.

register(plugin, name=None)

Registriert ein Plugin und gibt dessen Namen zurück.

Parameter:

name (str | None) – Der Name, unter dem das Plugin registriert werden soll. Wenn nicht angegeben, wird ein Name mithilfe von get_canonical_name() generiert.

Gibt zurück:

Der Plugin-Name. Wenn der Name für die Registrierung blockiert ist, wird None zurückgegeben.

Rückgabetyp:

str | None

Wenn das Plugin bereits registriert ist, wird ein ValueError ausgelöst.

getplugin(name)

hasplugin(name)

Gibt zurück, ob ein Plugin mit dem angegebenen Namen registriert ist.

import_plugin(modname, consider_entry_points=False)

Importiert ein Plugin mit modname.

Wenn consider_entry_points True ist, werden auch Entry-Point-Namen berücksichtigt, um ein Plugin zu finden.

add_hookcall_monitoring(before, after)

Fügt Vor-/Nach-Tracing-Funktionen für alle Hooks hinzu.

Gibt eine Undo-Funktion zurück, die, wenn sie aufgerufen wird, die hinzugefügten Tracer entfernt.

before(hook_name, hook_impls, kwargs) wird vor allen Hook-Aufrufen aufgerufen und erhält eine Hook-Aufrufer-Instanz, eine Liste von HookImpl-Instanzen und die Schlüsselwortargumente für den Hook-Aufruf.

after(outcome, hook_name, hook_impls, kwargs) empfängt dieselben Argumente wie before, aber auch ein Result-Objekt, das das Ergebnis des gesamten Hook-Aufrufs darstellt.

add_hookspecs(module_or_class)

Fügt neue Hook-Spezifikationen hinzu, die im angegebenen module_or_class definiert sind.

Funktionen werden als Hook-Spezifikationen erkannt, wenn sie mit einem passenden HookspecMarker dekoriert wurden.

check_pending()

Überprüft, ob alle Hooks, die nicht gegen eine Hook-Spezifikation verifiziert wurden, optional sind, andernfalls wird PluginValidationError ausgelöst.

enable_tracing()

Aktiviert das Tracing von Hook-Aufrufen.

Gibt eine Undo-Funktion zurück, die, wenn sie aufgerufen wird, das hinzugefügte Tracing entfernt.

get_canonical_name(plugin)

Gibt einen kanonischen Namen für ein Plugin-Objekt zurück.

Beachten Sie, dass ein Plugin unter einem anderen Namen registriert werden kann, der vom Aufrufer von register(plugin, name) angegeben wird. Um den Namen eines registrierten Plugins zu erhalten, verwenden Sie stattdessen get_name(plugin).

get_hookcallers(plugin)

Ruft alle Hook-Aufrufer für das angegebene Plugin ab.

Gibt zurück:

Die Hook-Aufrufer oder None, wenn plugin in diesem Plugin-Manager nicht registriert ist.

Rückgabetyp:

list[HookCaller] | None

get_name(plugin)

Gibt den Namen zurück, unter dem das Plugin registriert ist, oder None, wenn nicht.

get_plugin(name)

Gibt das unter dem angegebenen Namen registrierte Plugin zurück, falls vorhanden.

get_plugins()

Gibt eine Menge aller registrierten Plugin-Objekte zurück.

has_plugin(name)

Gibt zurück, ob ein Plugin mit dem angegebenen Namen registriert ist.

is_blocked(name)

Gibt zurück, ob der angegebene Plugin-Name blockiert ist.

is_registered(plugin)

Gibt zurück, ob das Plugin bereits registriert ist.

list_name_plugin()

Gibt eine Liste von (name, plugin)-Paaren für alle registrierten Plugins zurück.

list_plugin_distinfo()

Gibt eine Liste von (plugin, distinfo)-Paaren für alle von Setuptools registrierten Plugins zurück.

load_setuptools_entrypoints(group, name=None)

Lädt Module aus der Abfrage der angegebenen Setuptools group.

Parameter:

• group (str) – Entry-Point-Gruppe zum Laden von Plugins.

• name (str | None) – Wenn angegeben, werden nur Plugins mit dem angegebenen name geladen.

Gibt zurück:

Die Anzahl der von diesem Aufruf geladenen Plugins.

Rückgabetyp:

int

set_blocked(name)

Blockiert die Registrierung des angegebenen Namens, de registriert ihn, falls er bereits registriert ist.

subset_hook_caller(name, remove_plugins)

Gibt eine Proxy-HookCaller-Instanz für die benannte Methode zurück, die Aufrufe an alle registrierten Plugins verwaltet, außer denen aus remove_plugins.

unblock(name)

Hebt die Blockierung eines Namens auf.

Gibt zurück, ob der Name tatsächlich blockiert war.

unregister(plugin=None, name=None)

De registriert ein Plugin und alle seine Hook-Implementierungen.

Das Plugin kann entweder über das Plugin-Objekt oder den Plugin-Namen angegeben werden. Wenn beides angegeben ist, müssen sie übereinstimmen.

Gibt das de registrierte Plugin zurück oder None, wenn es nicht gefunden wurde.

project_name: Final

Der Projektname.

hook: Final

Das „Hook-Relais“, das zum Aufrufen eines Hooks bei allen registrierten Plugins verwendet wird. Siehe Aufrufen von Hooks.

trace: Final[_tracing.TagTracerSub]

Der Tracing-Einstiegspunkt. Siehe Integriertes Tracing.

RaisesExc

final class RaisesExc

Hinzugefügt in Version 8.4.

Dies ist die Klasse, die beim Aufruf von pytest.raises() erstellt wird, kann aber direkt als Hilfsklasse mit RaisesGroup verwendet werden, wenn Sie Anforderungen an Unterausnahmen angeben möchten.

Sie benötigen dies nicht, wenn Sie nur den Typ angeben möchten, da RaisesGroup type[BaseException] akzeptiert.

Parameter:

• expected_exception (type[BaseException] | tuple[type[BaseException]] | None) –

  Der erwartete Typ oder einer von mehreren möglichen Typen. Kann None sein, um nur match und/oder check zu verwenden.

  Der Typ wird mit isinstance() überprüft und muss keine exakte Übereinstimmung sein. Wenn dies gewünscht ist, können Sie den Parameter check verwenden.

• match (str | Pattern[str]) – Ein Regex zum Abgleichen.

• check (Callable[[BaseException], bool]) – Wenn angegeben, ein aufrufbares Objekt, das mit der Ausnahme als Parameter aufgerufen wird, nachdem der Typ und der Match-Regex (falls angegeben) überprüft wurden. Wenn es True zurückgibt, wird es als Übereinstimmung betrachtet, andernfalls als fehlgeschlagene Übereinstimmung.

RaisesExc.matches() kann auch eigenständig verwendet werden, um einzelne Ausnahmen zu überprüfen.

Beispiele

with RaisesGroup(RaisesExc(ValueError, match="string"))
    ...
with RaisesGroup(RaisesExc(check=lambda x: x.args == (3, "hello"))):
    ...
with RaisesGroup(RaisesExc(check=lambda x: type(x) is ValueError)):
    ...

fail_reason

Wird nach einem Aufruf von matches() gesetzt, um einen menschenlesbaren Grund für das Fehlschlagen des Matches anzugeben. Bei Verwendung als Kontextmanager wird der String als Grund für das Fehlschlagen des Tests ausgegeben.

matches(exception)

Prüft, ob eine Ausnahme den Anforderungen dieser RaisesExc entspricht. Wenn dies fehlschlägt, wird RaisesExc.fail_reason gesetzt.

Beispiele

assert RaisesExc(ValueError).matches(my_exception):
# is equivalent to
assert isinstance(my_exception, ValueError)

# this can be useful when checking e.g. the ``__cause__`` of an exception.
with pytest.raises(ValueError) as excinfo:
    ...
assert RaisesExc(SyntaxError, match="foo").matches(excinfo.value.__cause__)
# above line is equivalent to
assert isinstance(excinfo.value.__cause__, SyntaxError)
assert re.search("foo", str(excinfo.value.__cause__)

RaisesGroup

Tutorial: Assertions über erwartete Ausnahmegruppen

final class RaisesGroup

Hinzugefügt in Version 8.4.

Kontextmanager zur Überprüfung einer erwarteten ExceptionGroup. Funktioniert ähnlich wie pytest.raises(), erlaubt aber die Angabe der Struktur einer ExceptionGroup. ExceptionInfo.group_contains() versucht ebenfalls, Ausnahmegruppen zu handhaben, ist aber sehr schlecht darin, zu überprüfen, ob Sie *keine* unerwarteten Ausnahmen erhalten haben.

Das Erfassungsverhalten unterscheidet sich von except*, da es standardmäßig viel strenger bezüglich der Struktur ist. Durch die Verwendung von allow_unwrapped=True und flatten_subgroups=True können Sie except* vollständig abgleichen, wenn eine einzelne Ausnahme erwartet wird.

Parameter:

• args –

  Beliebige Anzahl von Ausnahmetypen, RaisesGroup oder RaisesExc, um die in dieser Ausnahme enthaltenen Ausnahmen anzugeben. Alle angegebenen Ausnahmen müssen in der ausgelösten Gruppe vorhanden sein, *und keine anderen*.

  Wenn Sie eine variable Anzahl von Ausnahmen erwarten, müssen Sie pytest.raises(ExceptionGroup) verwenden und die enthaltenen Ausnahmen manuell überprüfen. Erwägen Sie die Verwendung von RaisesExc.matches().

  Die Reihenfolge der Ausnahmen spielt keine Rolle, daher ist RaisesGroup(ValueError, TypeError) äquivalent zu RaisesGroup(TypeError, ValueError).

• match (str | re.Pattern[str] | None) –

  Wenn angegeben, ein String, der einen regulären Ausdruck enthält, oder ein reguläres Ausdrucksobjekt, das gegen die String-Darstellung der Ausnahmegruppe und ihre PEP 678 __notes__ mit re.search() getestet wird.

  Um einen literalen String abzugleichen, der Sonderzeichen enthalten kann, kann das Muster zuerst mit re.escape() escaped werden.

  Beachten Sie, dass „ (5 subgroups)“ aus der repr vor dem Abgleichen entfernt wird.

• check (Callable[[E], bool]) – Wenn angegeben, ein aufrufbares Objekt, das mit der Gruppe als Parameter aufgerufen wird, nachdem die erwarteten Ausnahmen erfolgreich abgeglichen wurden. Wenn es True zurückgibt, wird es als Übereinstimmung betrachtet, andernfalls als fehlgeschlagene Übereinstimmung.

• allow_unwrapped (bool) –

  Wenn eine einzelne Ausnahme oder RaisesExc erwartet wird, wird sie auch dann abgeglichen, wenn die Ausnahme nicht innerhalb einer Ausnahmegruppe liegt.

  Die Verwendung zusammen mit match, check oder dem Erwarten mehrerer Ausnahmen löst einen Fehler aus.

• flatten_subgroups (bool) – „glättet“ alle Gruppen innerhalb der ausgelösten Ausnahmegruppe und extrahiert alle Ausnahmen aus verschachtelten Gruppen, bevor abgeglichen wird. Ohne diese Option wird erwartet, dass Sie die Verschachtelungsstruktur vollständig angeben, indem Sie RaisesGroup als erwarteten Parameter übergeben.

Beispiele

with RaisesGroup(ValueError):
    raise ExceptionGroup("", (ValueError(),))
# match
with RaisesGroup(
    ValueError,
    ValueError,
    RaisesExc(TypeError, match="^expected int$"),
    match="^my group$",
):
    raise ExceptionGroup(
        "my group",
        [
            ValueError(),
            TypeError("expected int"),
            ValueError(),
        ],
    )
# check
with RaisesGroup(
    KeyboardInterrupt,
    match="^hello$",
    check=lambda x: isinstance(x.__cause__, ValueError),
):
    raise BaseExceptionGroup("hello", [KeyboardInterrupt()]) from ValueError
# nested groups
with RaisesGroup(RaisesGroup(ValueError)):
    raise ExceptionGroup("", (ExceptionGroup("", (ValueError(),)),))

# flatten_subgroups
with RaisesGroup(ValueError, flatten_subgroups=True):
    raise ExceptionGroup("", (ExceptionGroup("", (ValueError(),)),))

# allow_unwrapped
with RaisesGroup(ValueError, allow_unwrapped=True):
    raise ValueError

RaisesGroup.matches() kann auch direkt verwendet werden, um eine eigenständige Ausnahmegruppe zu überprüfen.

Der Abgleichsalgorithmus ist gierig, was bedeutet, dass Fälle wie der folgende fehlschlagen können.

with RaisesGroup(ValueError, RaisesExc(ValueError, match="hello")):
    raise ExceptionGroup("", (ValueError("hello"), ValueError("goodbye")))

obwohl er im Allgemeinen die Reihenfolge der Ausnahmen in der Gruppe nicht berücksichtigt. Um das obige zu vermeiden, sollten Sie die erste ValueError mit einer RaisesExc angeben.

Hinweis

Wenn die ausgelösten Ausnahmen nicht mit den erwarteten übereinstimmen, erhalten Sie eine detaillierte Fehlermeldung, die erklärt, warum. Dies schließt repr(check) ein, falls gesetzt, was in Python übermäßig ausführlich sein kann und Speicherorte usw. anzeigt.

Wenn die Bibliothek hypothesis installiert und importiert ist (z. B. in conftest.py), wird diese Ausgabe von Hypothesis monkeypatched, um kürzere und besser lesbare Repräsentationen bereitzustellen.

fail_reason

Wird nach einem Aufruf von matches() gesetzt, um einen menschenlesbaren Grund für das Fehlschlagen des Matches anzugeben. Bei Verwendung als Kontextmanager wird der String als Grund für das Fehlschlagen des Tests ausgegeben.

matches(exception: BaseException | None) → TypeGuard[ExceptionGroup[ExcT_1]]

matches(exception: BaseException | None) → TypeGuard[BaseExceptionGroup[BaseExcT_1]]

Prüft, ob eine Ausnahme den Anforderungen dieser RaisesGroup entspricht. Wenn dies fehlschlägt, wird RaisesGroup.fail_reason gesetzt.

Beispiel

with pytest.raises(TypeError) as excinfo:
    ...
assert RaisesGroup(ValueError).matches(excinfo.value.__cause__)
# the above line is equivalent to
myexc = excinfo.value.__cause
assert isinstance(myexc, BaseExceptionGroup)
assert len(myexc.exceptions) == 1
assert isinstance(myexc.exceptions[0], ValueError)

TerminalReporter

final class TerminalReporter(config, file=None)

wrap_write(content, *, flush=False, margin=8, line_sep='\n', **markup)

Wickelt Nachrichten mit Rand für Fortschrittsinformationen.

rewrite(line, **markup)

Spult den Terminalcursor zum Anfang zurück und schreibt die angegebene Zeile.

Parameter:

erase – Wenn True, werden auch Leerzeichen bis zur vollen Terminalbreite hinzugefügt, um sicherzustellen, dass vorherige Zeilen korrekt gelöscht werden.

Die restlichen Schlüsselwortargumente sind Markup-Anweisungen.

build_summary_stats_line()

Erstellt die Teile, die in der letzten Zusammenfassungsstatistik-Zeile verwendet werden.

Die Zusammenfassungsstatistik-Zeile ist die Zeile, die am Ende angezeigt wird: „=== 12 passed, 2 errors in Xs===“.

Diese Funktion erstellt eine Liste der „Teile“, aus denen der Text in dieser Zeile besteht, im obigen Beispiel wäre es

[
    ("12 passed", {"green": True}),
    ("2 errors", {"red": True}
]

Das letzte Wörterbuch für jede Zeile ist ein „Markup-Wörterbuch“, das von TerminalWriter zur Farbgebung der Ausgabe verwendet wird.

Die endgültige Farbe der Zeile wird ebenfalls von dieser Funktion bestimmt und ist das zweite Element des zurückgegebenen Tupels.

TestReport

class TestReport

Basisklassen: BaseReport

Grundlegendes Testberichtsobjekt (wird auch für Setup- und Teardown-Aufrufe verwendet, wenn diese fehlschlagen).

Berichte können beliebige zusätzliche Attribute enthalten.

nodeid: str

Normalisierte Sammlungs-Knoten-ID.

location: tuple[str, int | None, str]

Ein Tupel (Dateipfad, Zeilennummer, Domaininfo), das den tatsächlichen Speicherort eines Testelements angibt – er kann sich vom gesammelten unterscheiden, z. B. wenn eine Methode von einem anderen Modul geerbt wird. Der Dateipfad kann relativ zu config.rootdir sein. Die Zeilennummer ist 0-basiert.

keywords: Mapping[str, Any]

Ein Dictionary aus Namen und Werten, das alle mit einer Testausführung verbundenen Schlüsselwörter und Marker enthält.

outcome: Literal['passed', 'failed', 'skipped']

Test-Ergebnis, immer einer von „passed“, „failed“, „skipped“.

longrepr: None | ExceptionInfo[BaseException] | tuple[str, int, str] | str | TerminalRepr

None oder eine Fehlerdarstellung.

when: Literal['setup', 'call', 'teardown']

Einer von 'setup', 'call', 'teardown', um die Testphase anzugeben.

user_properties

User properties ist eine Liste von Tupeln (Name, Wert), die benutzerdefinierte Eigenschaften des Tests enthält.

sections: list[tuple[str, str]]

Tupel aus Zeichenketten (Überschrift, Inhalt) mit zusätzlichen Informationen für den Testbericht. Wird von pytest verwendet, um Text aus stdout, stderr und abgefangenen Protokollereignissen hinzuzufügen. Kann von anderen Plugins verwendet werden, um beliebige Informationen zu Berichten hinzuzufügen.

duration: float

Zeit, die nur für die Ausführung des Tests benötigt wurde.

start: float

Die Systemzeit, zu der der Aufruf gestartet wurde, in Sekunden seit der Epoche.

stop: float

Die Systemzeit, zu der der Aufruf beendet wurde, in Sekunden seit der Epoche.

classmethod from_item_and_call(item, call)

Erstellt und füllt einen TestReport mit Standard-Item- und Call-Informationen.

Parameter:

• item (Item) – Das Item.

• call (CallInfo[None]) – Die Aufruf-Informationen.

property caplog: str

Gibt aufgezeichnete Protokollzeilen zurück, wenn die Protokollaufzeichnung aktiviert ist.

Hinzugefügt in Version 3.5.

property capstderr: str

Gibt aufgezeichneten Text von stderr zurück, wenn die Aufzeichnung aktiviert ist.

Hinzugefügt in Version 3.0.

property capstdout: str

Gibt aufgezeichneten Text von stdout zurück, wenn die Aufzeichnung aktiviert ist.

Hinzugefügt in Version 3.0.

property count_towards_summary: bool

Experimentell Ob dieser Bericht bei den am Ende der Test-Sitzung angezeigten Summen gezählt werden soll: „1 passed, 1 failure, etc.“.

Hinweis

Diese Funktion wird als experimentell betrachtet, daher beachten Sie, dass sie auch in Patch-Releases Änderungen unterliegen kann.

property failed: bool

Ob das Ergebnis fehlgeschlagen ist.

property fspath: str

Der Pfadteil des berichteten Knotens als Zeichenkette.

property head_line: str | None

Experimentell Die Kopfzeile, die mit der longrepr-Ausgabe für diesen Bericht angezeigt wird, häufiger während der Traceback-Darstellung bei Fehlern.

________ Test.foo ________

Im obigen Beispiel ist die Kopfzeile „Test.foo“.

Hinweis

Diese Funktion wird als experimentell betrachtet, daher beachten Sie, dass sie auch in Patch-Releases Änderungen unterliegen kann.

property longreprtext: str

Schreibgeschütztes Property, das die vollständige String-Darstellung von longrepr zurückgibt.

Hinzugefügt in Version 3.0.

property passed: bool

Ob das Ergebnis erfolgreich war.

property skipped: bool

Ob das Ergebnis übersprungen wurde.

TestShortLogReport

class TestShortLogReport

Wird verwendet, um die Ergebniskategorie, den Kurzbuchstaben und das ausführliche Wort des Testergebnisses zu speichern. Zum Beispiel "rerun", "R", ("RERUN", {"yellow": True}).

Variablen:

• category – Die Ergebniskategorie, zum Beispiel “passed”, “skipped”, “error” oder eine leere Zeichenkette.

• letter – Der Kurzbuchstabe, der während des Testfortschritts angezeigt wird, z.B. ".", "s", "E" oder eine leere Zeichenkette.

• word – Das ausführliche Wort, das während des Testfortschritts im ausführlichen Modus angezeigt wird, z.B. "PASSED", "SKIPPED", "ERROR" oder eine leere Zeichenkette.

category: str

Alias für Feldnummer 0

letter: str

Alias für Feldnummer 1

word: str | tuple[str, Mapping[str, bool]]

Alias für Feldnummer 2

Ergebnis

Ergebnisobjekt, das innerhalb von Hook-Wrapper verwendet wird. Weitere Informationen finden Sie unter Result in the pluggy documentation.

Stash

class Stash

Stash ist ein typsicheres, heterogenes, veränderliches Mapping, das es ermöglicht, Schlüssel und Werttypen separat von dort zu definieren, wo die Stash erstellt wird.

Normalerweise erhalten Sie ein Objekt, das eine Stash hat, z.B. ein Config oder ein Node.

stash: Stash = some_object.stash

Wenn ein Modul oder Plugin Daten in dieser Stash speichern möchte, erstellt es StashKeys für seine Schlüssel (auf Modulebene).

# At the top-level of the module
some_str_key = StashKey[str]()
some_bool_key = StashKey[bool]()

Zum Speichern von Informationen

# Value type must match the key.
stash[some_str_key] = "value"
stash[some_bool_key] = True

Zum Abrufen der Informationen

# The static type of some_str is str.
some_str = stash[some_str_key]
# The static type of some_bool is bool.
some_bool = stash[some_bool_key]

Hinzugefügt in Version 7.0.

__setitem__(key, value)

Setzt einen Wert für den Schlüssel.

__getitem__(key)

Ruft den Wert für den Schlüssel ab.

Löst KeyError aus, wenn der Schlüssel zuvor nicht gesetzt wurde.

get(key, default)

Ruft den Wert für den Schlüssel ab oder gibt default zurück, wenn der Schlüssel zuvor nicht gesetzt wurde.

setdefault(key, default)

Gibt den Wert des Schlüssels zurück, wenn er bereits gesetzt ist, andernfalls setzt er den Wert des Schlüssels auf default und gibt default zurück.

__delitem__(key)

Löscht den Wert für den Schlüssel.

Löst KeyError aus, wenn der Schlüssel zuvor nicht gesetzt wurde.

__contains__(key)

Gibt zurück, ob der Schlüssel gesetzt wurde.

__len__()

Gibt zurück, wie viele Elemente sich im Stash befinden.

class StashKey

Bases: Generic[T]

StashKey ist ein Objekt, das als Schlüssel für einen Stash verwendet wird.

Ein StashKey ist mit dem Typ T des Werts des Schlüssels verbunden.

Ein StashKey ist eindeutig und kann nicht mit einem anderen Schlüssel kollidieren.

Hinzugefügt in Version 7.0.

Globale Variablen

pytest behandelt einige globale Variablen besonders, wenn sie in einem Testmodul oder conftest.py-Dateien definiert werden.

collect_ignore

Tutorial: Anpassen der Testsammlung

Kann in conftest.py-Dateien deklariert werden, um Testverzeichnisse oder -module auszuschließen. Muss eine Liste von Pfaden sein (str, pathlib.Path oder jedes os.PathLike).

collect_ignore = ["setup.py"]

collect_ignore_glob

Tutorial: Anpassen der Testsammlung

Kann in conftest.py-Dateien deklariert werden, um Testverzeichnisse oder -module mit Unix-Shell-ähnlichen Wildcards auszuschließen. Muss list[str] sein, wobei str Glob-Muster enthalten kann.

collect_ignore_glob = ["*_ignore.py"]

pytest_plugins

Tutorial: Plugins in einem Testmodul oder conftest-Datei anfordern/laden

Kann auf der **globalen** Ebene in Testmodulen und conftest.py-Dateien deklariert werden, um zusätzliche Plugins zu registrieren. Kann entweder ein str oder eine Sequence[str] sein.

pytest_plugins = "myapp.testsupport.myplugin"

pytest_plugins = ("myapp.testsupport.tools", "myapp.testsupport.regression")

pytestmark

Tutorial: Markieren ganzer Klassen oder Module

Kann auf der **globalen** Ebene in Testmodulen deklariert werden, um alle Testfunktionen und -methoden mit einem oder mehreren Markern zu versehen. Kann entweder ein einzelner Marker oder eine Liste von Markern sein (die von links nach rechts angewendet werden).

import pytest

pytestmark = pytest.mark.webtest

import pytest

pytestmark = [pytest.mark.integration, pytest.mark.slow]

Umgebungsvariablen

Umgebungsvariablen, die verwendet werden können, um das Verhalten von pytest zu ändern.

CI

Wenn auf einen nicht leeren Wert gesetzt, erkennt pytest, dass es in einem CI-Prozess läuft. Siehe auch CI-Pipelines.

BUILD_NUMBER

Wenn auf einen nicht leeren Wert gesetzt, erkennt pytest, dass es in einem CI-Prozess läuft. Alternative zu CI. Siehe auch CI-Pipelines.

PYTEST_ADDOPTS

Enthält eine Befehlszeile (geparst vom py:mod:shlex-Modul), die der vom Benutzer angegebenen Befehlszeile **vorangestellt** wird. Weitere Informationen finden Sie unter Standard-Konfigurationsdateioptionen.

PYTEST_VERSION

Diese Umgebungsvariable wird zu Beginn der pytest-Sitzung gesetzt und danach wieder gelöscht. Sie enthält den Wert von pytest.__version__ und kann unter anderem verwendet werden, um leicht zu überprüfen, ob ein Code innerhalb eines pytest-Laufs ausgeführt wird.

PYTEST_CURRENT_TEST

Diese ist nicht für Benutzer gedacht, wird aber von pytest intern mit dem Namen des aktuellen Tests gesetzt, damit andere Prozesse sie inspizieren können. Weitere Informationen finden Sie unter Umgebungsvariable PYTEST_CURRENT_TEST.

PYTEST_DEBUG

Wenn gesetzt, gibt pytest Trace- und Debug-Informationen aus.

PYTEST_DEBUG_TEMPROOT

Root für temporäre Verzeichnisse, die von Fixtures wie tmp_path erzeugt werden, wie in Speicherort und Aufbewahrung temporärer Verzeichnisse diskutiert.

PYTEST_DISABLE_PLUGIN_AUTOLOAD

Wenn gesetzt, deaktiviert das automatische Laden von Plugins über Entry Point-Paketierungsmetadaten. Nur Plugins, die explizit in PYTEST_PLUGINS angegeben oder mit -p aufgeführt sind, werden geladen. Siehe auch –disable-plugin-autoload.

PYTEST_PLUGINS

Enthält eine durch Kommas getrennte Liste von Modulen, die als Plugins geladen werden sollen.

export PYTEST_PLUGINS=mymodule.plugin,xdist

Siehe auch -p.

PYTEST_THEME

Setzt einen Pygments-Stil für die Codeausgabe.

PYTEST_THEME_MODE

Setzt PYTEST_THEME auf entweder dark oder light.

PY_COLORS

Wenn auf 1 gesetzt, verwendet pytest Farbe in der Terminalausgabe. Wenn auf 0 gesetzt, verwendet pytest keine Farbe. PY_COLORS hat Vorrang vor NO_COLOR und FORCE_COLOR.

NO_COLOR

Wenn auf eine nicht leere Zeichenkette gesetzt (unabhängig vom Wert), verwendet pytest keine Farbe in der Terminalausgabe. PY_COLORS hat Vorrang vor NO_COLOR, was Vorrang vor FORCE_COLOR hat. Siehe no-color.org für andere Bibliotheken, die diesen Community-Standard unterstützen.

FORCE_COLOR

Wenn auf eine nicht leere Zeichenkette gesetzt (unabhängig vom Wert), verwendet pytest Farbe in der Terminalausgabe. PY_COLORS und NO_COLOR haben Vorrang vor FORCE_COLOR.

Ausnahmen

exception UsageError

Bases: Exception

Fehler bei der Verwendung oder einem Aufruf von pytest.

final exception FixtureLookupError

Bases: LookupError

Ein angeforderter Fixture konnte nicht zurückgegeben werden (fehlend oder ungültig).

Warnungen

Benutzerdefinierte Warnungen, die in bestimmten Situationen ausgegeben werden, z.B. bei unsachgemäßer Verwendung oder veralteten Funktionen.

class PytestWarning

Bases: UserWarning

Basisklasse für alle von pytest ausgegebenen Warnungen.

class PytestAssertRewriteWarning

Bases: PytestWarning

Warnung, die vom pytest assert rewrite-Modul ausgegeben wird.

class PytestCacheWarning

Bases: PytestWarning

Warnung, die vom Cache-Plugin in verschiedenen Situationen ausgegeben wird.

class PytestCollectionWarning

Bases: PytestWarning

Warnung, die ausgegeben wird, wenn pytest eine Datei oder ein Symbol in einem Modul nicht sammeln kann.

class PytestConfigWarning

Bases: PytestWarning

Warnung, die für Konfigurationsprobleme ausgegeben wird.

class PytestDeprecationWarning

Bases: PytestWarning, DeprecationWarning

Warnungsklasse für Funktionen, die in einer zukünftigen Version entfernt werden.

class PytestExperimentalApiWarning

Bases: PytestWarning, FutureWarning

Warnungskategorie, die verwendet wird, um Experimente in pytest zu kennzeichnen.

Sparsam verwenden, da die API in einer zukünftigen Version geändert oder sogar vollständig entfernt werden kann.

class PytestReturnNotNoneWarning

Bases: PytestWarning

Warnung, die ausgegeben wird, wenn eine Testfunktion einen anderen Wert als None zurückgibt.

Details finden Sie unter Rückgabe eines Werts ungleich None in Testfunktionen.

class PytestRemovedIn9Warning

Bases: PytestDeprecationWarning

Warnungsklasse für Funktionen, die in pytest 9 entfernt werden.

class PytestUnknownMarkWarning

Bases: PytestWarning

Warnung, die bei der Verwendung unbekannter Marker ausgegeben wird.

Details finden Sie unter So kennzeichnen Sie Testfunktionen mit Attributen.

class PytestUnraisableExceptionWarning

Bases: PytestWarning

Eine nicht aufhebbare Ausnahme wurde gemeldet.

Unraisable Ausnahmen sind Ausnahmen, die in __del__ Implementierungen und ähnlichen Situationen ausgelöst werden, wenn die Ausnahme nicht normal ausgelöst werden kann.

Klasse PytestUnhandledThreadExceptionWarning

Bases: PytestWarning

Eine unbehandelte Ausnahme ist in einem Thread aufgetreten.

Solche Ausnahmen breiten sich nicht normal aus.

Weitere Informationen finden Sie im Abschnitt Interne pytest-Warnungen der Dokumentation.

Konfigurationsoptionen

Hier ist eine Liste von integrierten Konfigurationsoptionen, die in einer pytest.ini (oder .pytest.ini), pyproject.toml, tox.ini oder setup.cfg Datei geschrieben werden können, die sich normalerweise am Stammverzeichnis Ihres Repositories befindet.

Einzelheiten zu jedem Dateiformat finden Sie unter Konfigurationsdateiformate.

Warnung

Die Verwendung von setup.cfg wird außer für sehr einfache Anwendungsfälle nicht empfohlen. .cfg Dateien verwenden einen anderen Parser als pytest.ini und tox.ini, was zu schwer zu findenden Problemen führen kann. Wenn möglich, wird empfohlen, letztere Dateien oder pytest.toml oder pyproject.toml für Ihre pytest-Konfiguration zu verwenden.

Konfigurationsoptionen können auf der Befehlszeile mit -o/--override-ini überschrieben werden, was auch mehrmals übergeben werden kann. Das erwartete Format ist name=wert. Zum Beispiel

pytest -o console_output_style=classic -o cache_dir=/tmp/mycache

addopts

Fügt die angegebenen OPTS zum Satz von Befehlszeilenargumenten hinzu, als ob sie vom Benutzer angegeben worden wären. Beispiel: Wenn Sie diesen Inhalt der Konfigurationsdatei haben

# content of pytest.toml
[pytest]
addopts = ["--maxfail=2", "-rf"]  # exit after 2 failures, report fail info

Die Ausgabe von pytest test_hello.py bedeutet tatsächlich

pytest --maxfail=2 -rf test_hello.py

Standardmäßig werden keine Optionen hinzugefügt.

cache_dir

Legt das Verzeichnis fest, in dem der Inhalt des Cache-Plugins gespeichert wird. Das Standardverzeichnis ist .pytest_cache, das im rootdir erstellt wird. Das Verzeichnis kann ein relativer oder absoluter Pfad sein. Bei Angabe eines relativen Pfads wird das Verzeichnis relativ zum rootdir erstellt. Zusätzlich kann ein Pfad Umgebungsvariablen enthalten, die erweitert werden. Weitere Informationen zum Cache-Plugin finden Sie unter Wie man fehlgeschlagene Tests erneut ausführt und den Zustand zwischen Testläufen beibehält.

collect_imported_tests

Hinzugefügt in Version 8.4.

Wenn dies auf false gesetzt wird, sammelt pytest Klassen/Funktionen aus Testdateien **nur**, wenn sie in dieser Datei definiert sind (im Gegensatz zum Importieren dort).

toml

[pytest]
collect_imported_tests = false

ini

[pytest]
collect_imported_tests = false

Standard: true

Pytest sammelt traditionell Klassen/Funktionen im Namensraum des Testmoduls, auch wenn sie aus einer anderen Datei importiert wurden.

Zum Beispiel

# contents of src/domain.py
class Testament: ...


# contents of tests/test_testament.py
from domain import Testament


def test_testament(): ...

In diesem Szenario werden mit den Standardoptionen die Klasse Testament aus tests/test_testament.py gesammelt, da sie mit Test beginnt, obwohl es sich in diesem Fall um eine Produktionsklasse handelt, die in den Namensraum des Testmoduls importiert wird.

Das Setzen von collected_imported_tests auf false in der Konfigurationsdatei verhindert dies.

consider_namespace_packages

Steuert, ob pytest versuchen soll, Namespace-Pakete beim Sammeln von Python-Modulen zu identifizieren. Standard ist False.

Setzen Sie auf True, wenn das zu testende Paket Teil eines Namespace-Pakets ist. Namespace-Pakete werden auch als --pyargs Ziel unterstützt.

Nur native Namespace-Pakete werden unterstützt, es gibt keine Pläne, Legacy-Namespace-Pakete zu unterstützen.

Hinzugefügt in Version 8.1.

console_output_style

Legt den Stil der Konsolenausgabe während der Testausführung fest

• classic: klassische pytest-Ausgabe.

• progress: wie klassische pytest-Ausgabe, aber mit Fortschrittsanzeige.

• progress-even-when-capture-no: ermöglicht die Verwendung der Fortschrittsanzeige auch bei capture=no.

• count: wie Fortschritt, zeigt aber den Fortschritt als Anzahl der abgeschlossenen Tests anstelle eines Prozentsatzes.

• times: zeigt die Dauer der Tests an.

Standard ist progress, aber Sie können auf classic zurückfallen, wenn Sie es bevorzugen oder der neue Modus unerwartete Probleme verursacht.

toml

[pytest]
console_output_style = "classic"

ini

[pytest]
console_output_style = classic

disable_test_id_escaping_and_forfeit_all_rights_to_community_support

Hinzugefügt in Version 4.4.

Pytest maskiert standardmäßig alle Nicht-ASCII-Zeichen, die in Unicode-Zeichenketten für die Parametrisierung verwendet werden, da dies mehrere Nachteile hat. Wenn Sie jedoch Unicode-Zeichenketten in der Parametrisierung verwenden und diese als solche (nicht maskiert) im Terminal sehen möchten, verwenden Sie diese Option in Ihrer Konfigurationsdatei.

toml

[pytest]
disable_test_id_escaping_and_forfeit_all_rights_to_community_support = true

ini

[pytest]
disable_test_id_escaping_and_forfeit_all_rights_to_community_support = true

Beachten Sie jedoch, dass dies unerwünschte Nebeneffekte und sogar Fehler verursachen kann, abhängig vom verwendeten Betriebssystem und den aktuell installierten Plugins. Verwenden Sie es daher auf eigene Gefahr.

Standard: False.

Siehe @pytest.mark.parametrize: Parametrisieren von Testfunktionen.

doctest_encoding

Standardkodierung zum Dekodieren von Textdateien mit Docstrings. So verarbeitet pytest Doctests.

doctest_optionflags

Ein oder mehrere Doctest-Flagnamen aus dem Standardmodul doctest. So verarbeitet pytest Doctests.

empty_parameter_set_mark

Ermöglicht die Auswahl der Aktion für leere Parametersätze in der Parametrisierung

• skip überspringt Tests mit einem leeren Parametersatz (Standard)

• xfail markiert Tests mit einem leeren Parametersatz als xfail (run=False)

• fail_at_collect löst eine Ausnahme aus, wenn parametrize einen leeren Parametersatz sammelt

toml

[pytest]
empty_parameter_set_mark = "xfail"

ini

[pytest]
empty_parameter_set_mark = xfail

Hinweis

Der Standardwert dieser Option wird in zukünftigen Versionen voraussichtlich auf xfail geändert, da dies als weniger fehleranfällig gilt. Weitere Details finden Sie unter #3155.

enable_assertion_pass_hook

Aktiviert den Hook pytest_assertion_pass. Stellen Sie sicher, dass alle zuvor generierten .pyc Cache-Dateien gelöscht werden.

toml

[pytest]
enable_assertion_pass_hook = true

ini

[pytest]
enable_assertion_pass_hook = true

faulthandler_exit_on_timeout

Beendet den pytest-Prozess nach Erreichen des Timeout für einzelne Tests, indem exit=True an die Funktion faulthandler.dump_traceback_later() übergeben wird. Dies ist besonders nützlich, um CI-Ressourcenverschwendung bei Testsuiten zu vermeiden, die den Haupt-Python-Interpreter in einen Deadlock-Zustand versetzen können.

Diese Option ist standardmäßig auf „false“ gesetzt.

toml

[pytest]
faulthandler_timeout = 5
faulthandler_exit_on_timeout = true

ini

[pytest]
faulthandler_timeout = 5
faulthandler_exit_on_timeout = true

faulthandler_timeout

Gibt die Tracebacks aller Threads aus, wenn ein Test länger als X Sekunden dauert (einschließlich Setup und Teardown von Fixtures). Implementiert mit der Funktion faulthandler.dump_traceback_later(), sodass alle dortigen Vorbehalte gelten.

toml

[pytest]
faulthandler_timeout = 5

ini

[pytest]
faulthandler_timeout = 5

Weitere Informationen finden Sie unter Fehlerbehandler. Weitere Informationen finden Sie unter Fehlerbehandler.

filterwarnings

Legt eine Liste von Filtern und Aktionen fest, die für übereinstimmende Warnungen ausgeführt werden sollen. Standardmäßig werden alle während der Testsitzung ausgegebenen Warnungen am Ende der Testsitzung in einer Zusammenfassung angezeigt.

toml

[pytest]
filterwarnings = ["error", "ignore::DeprecationWarning"]

ini

[pytest]
filterwarnings =
    error
    ignore::DeprecationWarning

Dies weist pytest an, Deprecation-Warnungen zu ignorieren und alle anderen Warnungen in Fehler umzuwandeln. Weitere Informationen finden Sie unter Wie man Warnungen erfasst.

junit_duration_report

Hinzugefügt in Version 4.1.

Konfiguriert, wie Dauern im JUnit XML-Bericht aufgezeichnet werden

• total (Standard): Dauerzeiten, die gemeldet werden, umfassen Setup-, Aufruf- und Teardown-Zeiten.

• call: Dauerzeiten, die gemeldet werden, umfassen nur Aufrufzeiten, ohne Setup und Teardown.

toml

[pytest]
junit_duration_report = "call"

ini

[pytest]
junit_duration_report = call

junit_family

Hinzugefügt in Version 4.2.

Geändert in Version 6.1: Standard auf xunit2 geändert.

Konfiguriert das Format der generierten JUnit XML-Datei. Die möglichen Optionen sind

• xunit1 (oder legacy): erzeugt Ausgabe im alten Stil, kompatibel mit dem xunit 1.0 Format.

• xunit2: erzeugt Ausgabe im xunit 2.0 Stil, die besser mit den neuesten Jenkins-Versionen kompatibel sein sollte. **Dies ist der Standard**.

toml

[pytest]
junit_family = "xunit2"

ini

[pytest]
junit_family = xunit2

junit_log_passing_tests

Hinzugefügt in Version 4.6.

Wenn junit_logging != "no", wird konfiguriert, ob die erfasste Ausgabe für **erfolgreiche** Tests in die JUnit XML-Datei geschrieben werden soll. Standard ist True.

toml

[pytest]
junit_log_passing_tests = false

ini

[pytest]
junit_log_passing_tests = False

junit_logging

Hinzugefügt in Version 3.5.

Geändert in Version 5.4: Optionen log, all, out-err hinzugefügt.

Konfiguriert, ob die erfasste Ausgabe in die JUnit XML-Datei geschrieben werden soll. Gültige Werte sind

• log: schreibt nur die logging erfassten Ausgaben.

• system-out: schreibt die erfassten stdout Inhalte.

• system-err: schreibt die erfassten stderr Inhalte.

• out-err: schreibt sowohl die erfassten stdout als auch stderr Inhalte.

• all: schreibt die erfassten logging, stdout und stderr Inhalte.

• no (Standard): keine erfasste Ausgabe wird geschrieben.

toml

[pytest]
junit_logging = "system-out"

ini

[pytest]
junit_logging = system-out

junit_suite_name

Um den Namen des Root-Testsuite-XML-Elements festzulegen, können Sie die Option junit_suite_name in Ihrer Konfigurationsdatei festlegen.

toml

[pytest]
junit_suite_name = "my_suite"

ini

[pytest]
junit_suite_name = my_suite

log_auto_indent

Ermöglicht selektive automatische Einrückung von mehrzeiligen Log-Nachrichten.

Unterstützt die Befehlszeilenoption --log-auto-indent [wert] und die Konfigurationsoption log_auto_indent = [wert], um das automatische Einrückungsverhalten für die gesamte Protokollierung festzulegen.

[wert] kann sein

• True oder „On“ - Dynamische automatische Einrückung von mehrzeiligen Log-Nachrichten

• False oder „Off“ oder 0 - Keine automatische Einrückung von mehrzeiligen Log-Nachrichten (Standardverhalten)

• [positive Ganzzahl] - Automatische Einrückung von mehrzeiligen Log-Nachrichten um [Wert] Leerzeichen

toml

[pytest]
log_auto_indent = false

ini

[pytest]
log_auto_indent = false

Unterstützt das Übergeben des Keywords extra={"auto_indent": [wert]} an Aufrufe von logging.log(), um das automatische Einrückungsverhalten für jeden einzelnen Log-Eintrag zu spezifizieren. Das extra Keyword überschreibt den auf der Befehlszeile oder in der Konfiguration angegebenen Wert.

log_cli

Aktiviert die Log-Anzeige während der Testausführung (auch bekannt als „Live-Protokollierung“). Der Standardwert ist False.

toml

[pytest]
log_cli = true

ini

[pytest]
log_cli = true

log_cli_date_format

Legt eine mit time.strftime() kompatible Zeichenkette fest, die zur Formatierung von Daten für die Live-Protokollierung verwendet wird.

toml

[pytest]
log_cli_date_format = "%Y-%m-%d %H:%M:%S"

ini

[pytest]
log_cli_date_format = %Y-%m-%d %H:%M:%S

Weitere Informationen finden Sie unter Live-Logs.

log_cli_format

Legt eine mit logging kompatible Zeichenkette fest, die zur Formatierung von Live-Log-Nachrichten verwendet wird.

toml

[pytest]
log_cli_format = "%(asctime)s %(levelname)s %(message)s"

ini

[pytest]
log_cli_format = %(asctime)s %(levelname)s %(message)s

Weitere Informationen finden Sie unter Live-Logs.

log_cli_level

Legt die minimale Log-Nachrichtenstufe fest, die für die Live-Protokollierung erfasst werden soll. Es können die ganzzahligen Werte oder die Namen der Stufen verwendet werden.

toml

[pytest]
log_cli_level = "INFO"

ini

[pytest]
log_cli_level = INFO

Weitere Informationen finden Sie unter Live-Logs.

log_date_format

Legt eine mit time.strftime() kompatible Zeichenkette fest, die zur Formatierung von Daten für die Protokollierungserfassung verwendet wird.

toml

[pytest]
log_date_format = "%Y-%m-%d %H:%M:%S"

ini

[pytest]
log_date_format = %Y-%m-%d %H:%M:%S

Weitere Informationen finden Sie unter Wie man die Protokollierung verwaltet.

log_file

Legt einen Dateinamen relativ zum aktuellen Arbeitsverzeichnis fest, in den Log-Nachrichten zusätzlich zu den anderen aktiven Protokollierungsfunktionen geschrieben werden sollen.

toml

[pytest]
log_file = "logs/pytest-logs.txt"

ini

[pytest]
log_file = logs/pytest-logs.txt

Weitere Informationen finden Sie unter Wie man die Protokollierung verwaltet.

log_file_date_format

Legt eine mit time.strftime() kompatible Zeichenkette fest, die zur Formatierung von Daten für die Protokolldatei verwendet wird.

toml

[pytest]
log_file_date_format = "%Y-%m-%d %H:%M:%S"

ini

[pytest]
log_file_date_format = %Y-%m-%d %H:%M:%S

Weitere Informationen finden Sie unter Wie man die Protokollierung verwaltet.

log_file_format

Legt eine mit logging kompatible Zeichenkette fest, die zur Formatierung von Log-Nachrichten verwendet wird, die in die Protokolldatei umgeleitet werden.

toml

[pytest]
log_file_format = "%(asctime)s %(levelname)s %(message)s"

ini

[pytest]
log_file_format = %(asctime)s %(levelname)s %(message)s

Weitere Informationen finden Sie unter Wie man die Protokollierung verwaltet.

log_file_level

Legt die minimale Log-Nachrichtenstufe fest, die für die Protokolldatei erfasst werden soll. Es können die ganzzahligen Werte oder die Namen der Stufen verwendet werden.

toml

[pytest]
log_file_level = "INFO"

ini

[pytest]
log_file_level = INFO

Weitere Informationen finden Sie unter Wie man die Protokollierung verwaltet.

log_file_mode

Legt den Modus fest, mit dem die Protokolldatei geöffnet wird. Die Optionen sind "w" zum Neuerstellen der Datei (Standard) oder "a" zum Anhängen an die Datei.

toml

[pytest]
log_file_mode = "a"

ini

[pytest]
log_file_mode = a

Weitere Informationen finden Sie unter Wie man die Protokollierung verwaltet.

log_format

Legt eine mit logging kompatible Zeichenkette fest, die zur Formatierung von erfassten Log-Nachrichten verwendet wird.

toml

[pytest]
log_format = "%(asctime)s %(levelname)s %(message)s"

ini

[pytest]
log_format = %(asctime)s %(levelname)s %(message)s

Weitere Informationen finden Sie unter Wie man die Protokollierung verwaltet.

log_level

Legt die minimale Log-Nachrichtenstufe fest, die für die Protokollierungserfassung erfasst werden soll. Es können die ganzzahligen Werte oder die Namen der Stufen verwendet werden.

toml

[pytest]
log_level = "INFO"

ini

[pytest]
log_level = INFO

Weitere Informationen finden Sie unter Wie man die Protokollierung verwaltet.

markers

Wenn die Konfigurationsoption strict_markers gesetzt ist, sind nur bekannte Marker – definiert im Code von core pytest oder einem Plugin – zulässig.

Sie können zusätzliche Marker in dieser Einstellung auflisten, um sie zur Whitelist hinzuzufügen. In diesem Fall möchten Sie wahrscheinlich strict_markers auf true setzen, um zukünftige Regressionen zu vermeiden.

toml

[pytest]
addopts = ["--strict-markers"]
markers = ["slow", "serial"]

ini

[pytest]
strict_markers = true
markers =
    slow
    serial

minversion

Gibt eine minimale pytest-Version an, die für die Ausführung von Tests erforderlich ist.

toml

[pytest]
minversion = 3.0  # will fail if we run with pytest-2.8

ini

[pytest]
minversion = 3.0  # will fail if we run with pytest-2.8

norecursedirs

Legt die Muster für Basisnamen von Verzeichnissen fest, die beim Rekursieren nach Testentdeckung vermieden werden sollen. Die einzelnen (fnmatch-artigen) Muster werden auf den Basisnamen eines Verzeichnisses angewendet, um zu entscheiden, ob es rekursiv durchsucht werden soll. Mustervergleichszeichen

*       matches everything
?       matches any single character
[seq]   matches any character in seq
[!seq]  matches any char not in seq

Standardmuster sind '*.egg', '.*', '_darcs', 'build', 'CVS', 'dist', 'node_modules', 'venv', '{arch}'. Das Setzen von norecursedirs ersetzt die Standardwerte. Hier ist ein Beispiel, wie bestimmte Verzeichnisse vermieden werden können

toml

[pytest]
norecursedirs = [".svn", "_build", "tmp*"]

ini

[pytest]
norecursedirs = .svn _build tmp*

Dies würde pytest anweisen, nicht in typische Subversion- oder sphinx-build-Verzeichnisse oder in Verzeichnisse mit dem Präfix tmp zu schauen.

Zusätzlich versucht pytest, eine virtuelle Umgebung intelligent zu identifizieren und zu ignorieren. Jedes Verzeichnis, das als Stammverzeichnis einer virtuellen Umgebung gilt, wird bei der Testsammlung nicht berücksichtigt, es sei denn, --collect-in-virtualenv wird angegeben. Beachten Sie auch, dass norecursedirs Vorrang vor --collect-in-virtualenv hat. Wenn Sie beispielsweise Tests in einer virtuellen Umgebung mit einem Basisverzeichnis ausführen möchten, das '.*' entspricht, **müssen** Sie norecursedirs überschreiben und zusätzlich das Flag --collect-in-virtualenv verwenden.

python_classes

Ein oder mehrere Namenspräfixe oder Glob-Muster, die bestimmen, welche Klassen für die Testsammlung berücksichtigt werden. Suchen Sie nach mehreren Glob-Mustern, indem Sie Leerzeichen zwischen den Mustern einfügen. Standardmäßig berücksichtigt pytest jede Klasse mit dem Präfix Test als Testsammlung. Hier ist ein Beispiel, wie Tests aus Klassen gesammelt werden können, die auf Suite enden.

toml

[pytest]
python_classes = ["*Suite"]

ini

[pytest]
python_classes = *Suite

Beachten Sie, dass von unittest.TestCase abgeleitete Klassen immer unabhängig von dieser Option gesammelt werden, da das eigene Sammel-Framework von unittest zur Sammlung dieser Tests verwendet wird.

python_files

Ein oder mehrere glob-artige Dateimuster, die bestimmen, welche Python-Dateien als Testmodule betrachtet werden. Suchen Sie nach mehreren Glob-Mustern, indem Sie Leerzeichen zwischen den Mustern einfügen.

toml

[pytest]
python_files = ["test_*.py", "check_*.py", "example_*.py"]

ini

[pytest]
python_files = test_*.py check_*.py example_*.py

Oder eine pro Zeile.

[pytest]
python_files =
    test_*.py
    check_*.py
    example_*.py

Standardmäßig werden Dateien, die mit test_*.py und *_test.py übereinstimmen, als Testmodule betrachtet.

python_functions

Ein oder mehrere Namenspräfixe oder Glob-Muster, die bestimmen, welche Testfunktionen und -methoden als Tests betrachtet werden. Suchen Sie nach mehreren Glob-Mustern, indem Sie Leerzeichen zwischen den Mustern einfügen. Standardmäßig betrachtet pytest jede Funktion mit dem Präfix test als Test. Hier ist ein Beispiel, wie Testfunktionen und -methoden gesammelt werden können, die auf _test enden.

toml

[pytest]
python_functions = ["*_test"]

ini

[pytest]
python_functions = *_test

Beachten Sie, dass dies keine Auswirkung auf Methoden hat, die in einer von unittest.TestCase abgeleiteten Klasse leben, da das eigene Sammel-Framework von unittest zur Sammlung dieser Tests verwendet wird.

Siehe Namenskonventionen ändern für detailliertere Beispiele.

pythonpath

Legt eine Liste von Verzeichnissen fest, die dem Python-Suchpfad hinzugefügt werden sollen. Verzeichnisse werden am Anfang von sys.path hinzugefügt. Ähnlich wie die Umgebungsvariable PYTHONPATH werden die Verzeichnisse dort einbezogen, wo Python nach importierten Modulen sucht. Pfade sind relativ zum rootdir Verzeichnis. Verzeichnisse bleiben für die Dauer der Testsitzung im Pfad.

toml

[pytest]
pythonpath = ["src1", "src2"]

ini

[pytest]
pythonpath = src1 src2

required_plugins

Eine durch Leerzeichen getrennte Liste von Plugins, die vorhanden sein müssen, damit pytest ausgeführt werden kann. Plugins können mit oder ohne Versionsspezifizierer direkt nach ihrem Namen aufgeführt werden. Leerzeichen zwischen verschiedenen Versionsspezifizierern sind nicht erlaubt. Wenn eines der Plugins nicht gefunden wird, wird ein Fehler ausgegeben.

toml

[pytest]
required_plugins = ["pytest-django>=3.0.0,<4.0.0", "pytest-html", "pytest-xdist>=1.0.0"]

ini

[pytest]
required_plugins = pytest-django>=3.0.0,<4.0.0 pytest-html pytest-xdist>=1.0.0

strict

Wenn auf true gesetzt, wird der „strict mode“ aktiviert, der die folgenden Optionen aktiviert:

• strict_config

• strict_markers

• strict_parametrization_ids

• strict_xfail

Plugins können auch ihre eigenen Strictness-Optionen aktivieren.

Wenn Sie eine einzelne Strictness-Option explizit setzen, hat diese Vorrang vor strict.

Hinweis

Wenn pytest in Zukunft neue Strictness-Optionen hinzufügt, werden diese auch im Strict-Modus aktiviert. Daher sollten Sie den Strict-Modus nur aktivieren, wenn Sie eine angepinnte/gesperrte Version von pytest verwenden oder wenn Sie neue Strictness-Optionen proaktiv übernehmen möchten, sobald sie hinzugefügt werden.

toml

[pytest]
strict = true

ini

[pytest]
strict = true

Hinzugefügt in Version 9.0.

strict_config

Wenn auf true gesetzt, werden alle Warnungen, die beim Parsen des pytest Abschnitts der Konfigurationsdatei auftreten, als Fehler behandelt.

toml

[pytest]
strict_config = true

ini

[pytest]
strict_config = true

Sie können diese Option auch über die Option strict aktivieren.

strict_markers

Wenn auf true gesetzt, lösen Marker, die nicht im Abschnitt markers der Konfigurationsdatei registriert sind, Fehler aus.

toml

[pytest]
strict_markers = true

ini

[pytest]
strict_markers = true

Sie können diese Option auch über die Option strict aktivieren.

strict_parametrization_ids

Wenn auf true gesetzt, gibt pytest einen Fehler aus, wenn es nicht eindeutige Parametersatz-IDs erkennt.

Wenn nicht gesetzt (Standard), behandelt pytest dies automatisch, indem es 0, 1, ... zu doppelten IDs hinzufügt und sie so eindeutig macht.

toml

[pytest]
strict_parametrization_ids = true

ini

[pytest]
strict_parametrization_ids = true

Sie können diese Option auch über die Option strict aktivieren.

Zum Beispiel,

import pytest


@pytest.mark.parametrize("letter", ["a", "a"])
def test_letter_is_ascii(letter):
    assert letter.isascii()

wird einen Fehler auslösen, da beide Fälle (Parametersätze) die gleiche automatisch generierte ID „a“ haben.

Um den Fehler zu beheben, weisen Sie explizit eindeutige IDs zu, wenn Sie die Duplikate beibehalten möchten.

import pytest


@pytest.mark.parametrize("letter", ["a", "a"], ids=["a0", "a1"])
def test_letter_is_ascii(letter):
    assert letter.isascii()

Siehe parametrize und pytest.param() für andere Möglichkeiten, IDs festzulegen.

strict_xfail

Wenn auf true gesetzt, schlagen Tests, die mit @pytest.mark.xfail markiert sind und tatsächlich erfolgreich sind, standardmäßig die Testsuite. Weitere Informationen finden Sie unter strict Parameter.

toml

[pytest]
strict_xfail = true

ini

[pytest]
strict_xfail = true

Sie können diese Option auch über die Option strict aktivieren.

Geändert in Version 9.0: Umbenannt von xfail_strict in strict_xfail. xfail_strict wird als Alias für strict_xfail akzeptiert.

testpaths

Legt eine Liste von Verzeichnissen fest, die nach Tests durchsucht werden sollen, wenn bei der Ausführung von pytest vom rootdir Verzeichnis keine spezifischen Verzeichnisse, Dateien oder Test-IDs auf der Befehlszeile angegeben werden. Dateisystempfade können Shell-ähnliche Wildcards verwenden, einschließlich des rekursiven Musters **.

Nützlich, wenn sich alle Projekt-Tests an einem bekannten Ort befinden, um die Testsammlung zu beschleunigen und versehentliches Aufnehmen unerwünschter Tests zu vermeiden.

toml

[pytest]
testpaths = ["testing", "doc"]

ini

[pytest]
testpaths = testing doc

Diese Konfiguration bedeutet, dass die Ausführung von

pytest

die gleichen praktischen Auswirkungen hat wie die Ausführung von

pytest testing doc

tmp_path_retention_count

Wie viele Sitzungen sollen die tmp_path Verzeichnisse beibehalten werden, gemäß tmp_path_retention_policy.

toml

[pytest]
tmp_path_retention_count = 3

ini

[pytest]
tmp_path_retention_count = 3

Standard: 3

tmp_path_retention_policy

Steuert, welche Verzeichnisse, die von der tmp_path Fixture erstellt wurden, basierend auf dem Testergebnis beibehalten werden.

• all: behält Verzeichnisse für alle Tests, unabhängig vom Ergebnis.

• failed: behält Verzeichnisse nur für Tests mit dem Ergebnis error oder failed.

• none: Verzeichnisse werden immer nach Abschluss jedes Tests entfernt, unabhängig vom Ergebnis.

toml

[pytest]
tmp_path_retention_policy = "all"

ini

[pytest]
tmp_path_retention_policy = all

Standard: all

truncation_limit_chars

Steuert die maximale Anzahl von Zeichen, um den Inhalt von Assertionsmeldungen zu kürzen.

Wenn der Wert auf 0 gesetzt wird, wird das Zeichenlimit für die Kürzung deaktiviert.

toml

[pytest]
truncation_limit_chars = 640

ini

[pytest]
truncation_limit_chars = 640

pytest kürzt die Assertionsmeldungen standardmäßig auf eine bestimmte Grenze, um zu verhindern, dass Vergleiche mit großen Datenmengen die Konsolenausgabe überlasten.

Standard: 640

Hinweis

Wenn pytest erkennt, dass es in einer CI-Umgebung ausgeführt wird, wird die Kürzung automatisch deaktiviert.

truncation_limit_lines

Steuert die maximale Anzahl von Zeilen, um den Inhalt von Assertionsmeldungen zu kürzen.

Wenn der Wert auf 0 gesetzt wird, wird das Zeilenlimit für die Kürzung deaktiviert.

toml

[pytest]
truncation_limit_lines = 8

ini

[pytest]
truncation_limit_lines = 8

pytest kürzt die Assertionsmeldungen standardmäßig auf eine bestimmte Grenze, um zu verhindern, dass Vergleiche mit großen Datenmengen die Konsolenausgabe überlasten.

Standard: 8

Hinweis

Wenn pytest erkennt, dass es in einer CI-Umgebung ausgeführt wird, wird die Kürzung automatisch deaktiviert.

usefixtures

Liste von Fixtures, die auf alle Testfunktionen angewendet werden; dies ist semantisch dasselbe wie die Anwendung des Markers @pytest.mark.usefixtures auf alle Testfunktionen.

toml

[pytest]
usefixtures = ["clean_db"]

ini

[pytest]
usefixtures =
    clean_db

verbosity_assertions

Legt eine Detailgenauigkeitsstufe speziell für assertionsbezogene Ausgaben fest und überschreibt die anwendungsweite Stufe.

toml

[pytest]
verbosity_assertions = "2"

ini

[pytest]
verbosity_assertions = 2

Wenn nicht gesetzt, wird standardmäßig die anwendungsweite Detailgenauigkeitsstufe (über die Kommandozeilenoption -v) verwendet. Ein spezieller Wert von "auto" kann verwendet werden, um explizit die globale Detailgenauigkeitsstufe zu verwenden.

verbosity_subtests

Legt die Detailgenauigkeitsstufe speziell für **erfolgreiche** Subtests fest.

toml

[pytest]
verbosity_subtests = "1"

ini

[pytest]
verbosity_subtests = 1

Ein Wert von 1 oder höher zeigt die Ausgabe für **erfolgreiche** Subtests an ( **fehlgeschlagene** Subtests werden immer gemeldet). Die Ausgabe für erfolgreiche Subtests kann mit dem Wert 0 unterdrückt werden, was die Kommandozeilenoption -v überschreibt.

Wenn nicht gesetzt, wird standardmäßig die anwendungsweite Detailgenauigkeitsstufe (über die Kommandozeilenoption -v) verwendet. Ein spezieller Wert von "auto" kann verwendet werden, um explizit die globale Detailgenauigkeitsstufe zu verwenden.

Siehe auch: Wie man Subtests verwendet.

verbosity_test_cases

Legt eine Detailgenauigkeitsstufe speziell für testfallausführungsbezogene Ausgaben fest und überschreibt die anwendungsweite Stufe.

toml

[pytest]
verbosity_test_cases = "2"

ini

[pytest]
verbosity_test_cases = 2

Wenn nicht gesetzt, wird standardmäßig die anwendungsweite Detailgenauigkeitsstufe (über die Kommandozeilenoption -v) verwendet. Ein spezieller Wert von "auto" kann verwendet werden, um explizit die globale Detailgenauigkeitsstufe zu verwenden.

Kommandozeilen-Flags

Alle Kommandozeilen-Flags erhalten Sie, indem Sie pytest --help ausführen.

$ pytest --help
usage: pytest [options] [file_or_dir] [file_or_dir] [...]

positional arguments:
  file_or_dir

general:
  -k EXPRESSION         Only run tests which match the given substring
                        expression. An expression is a Python evaluable
                        expression where all names are substring-matched
                        against test names and their parent classes.
                        Example: -k 'test_method or test_other' matches all
                        test functions and classes whose name contains
                        'test_method' or 'test_other', while -k 'not
                        test_method' matches those that don't contain
                        'test_method' in their names. -k 'not test_method
                        and not test_other' will eliminate the matches.
                        Additionally keywords are matched to classes and
                        functions containing extra names in their
                        'extra_keyword_matches' set, as well as functions
                        which have names assigned directly to them. The
                        matching is case-insensitive.
  -m MARKEXPR           Only run tests matching given mark expression. For
                        example: -m 'mark1 and not mark2'.
  --markers             show markers (builtin, plugin and per-project ones).
  -x, --exitfirst       Exit instantly on first error or failed test
  --maxfail=num         Exit after first num failures or errors
  --strict-config       Enables the strict_config option
  --strict-markers      Enables the strict_markers option
  --strict              Enables the strict option
  --fixtures, --funcargs
                        Show available fixtures, sorted by plugin appearance
                        (fixtures with leading '_' are only shown with '-v')
  --fixtures-per-test   Show fixtures per test
  --pdb                 Start the interactive Python debugger on errors or
                        KeyboardInterrupt
  --pdbcls=modulename:classname
                        Specify a custom interactive Python debugger for use
                        with --pdb.For example:
                        --pdbcls=IPython.terminal.debugger:TerminalPdb
  --trace               Immediately break when running each test
  --capture=method      Per-test capturing method: one of fd|sys|no|tee-sys
  -s                    Shortcut for --capture=no
  --runxfail            Report the results of xfail tests as if they were
                        not marked
  --lf, --last-failed   Rerun only the tests that failed at the last run (or
                        all if none failed)
  --ff, --failed-first  Run all tests, but run the last failures first. This
                        may re-order tests and thus lead to repeated fixture
                        setup/teardown.
  --nf, --new-first     Run tests from new files first, then the rest of the
                        tests sorted by file mtime
  --cache-show=[CACHESHOW]
                        Show cache contents, don't perform collection or
                        tests. Optional argument: glob (default: '*').
  --cache-clear         Remove all cache contents at start of test run
  --lfnf, --last-failed-no-failures={all,none}
                        With ``--lf``, determines whether to execute tests
                        when there are no previously (known) failures or
                        when no cached ``lastfailed`` data was found.
                        ``all`` (the default) runs the full test suite
                        again. ``none`` just emits a message about no known
                        failures and exits successfully.
  --sw, --stepwise      Exit on test failure and continue from last failing
                        test next time
  --sw-skip, --stepwise-skip
                        Ignore the first failing test but stop on the next
                        failing test. Implicitly enables --stepwise.
  --sw-reset, --stepwise-reset
                        Resets stepwise state, restarting the stepwise
                        workflow. Implicitly enables --stepwise.

Reporting:
  --durations=N         Show N slowest setup/test durations (N=0 for all)
  --durations-min=N     Minimal duration in seconds for inclusion in slowest
                        list. Default: 0.005 (or 0.0 if -vv is given).
  -v, --verbose         Increase verbosity
  --no-header           Disable header
  --no-summary          Disable summary
  --no-fold-skipped     Do not fold skipped tests in short summary.
  --force-short-summary
                        Force condensed summary output regardless of
                        verbosity level.
  -q, --quiet           Decrease verbosity
  --verbosity=VERBOSE   Set verbosity. Default: 0.
  -r chars              Show extra test summary info as specified by chars:
                        (f)ailed, (E)rror, (s)kipped, (x)failed, (X)passed,
                        (p)assed, (P)assed with output, (a)ll except passed
                        (p/P), or (A)ll. (w)arnings are enabled by default
                        (see --disable-warnings), 'N' can be used to reset
                        the list. (default: 'fE').
  --disable-warnings, --disable-pytest-warnings
                        Disable warnings summary
  -l, --showlocals      Show locals in tracebacks (disabled by default)
  --no-showlocals       Hide locals in tracebacks (negate --showlocals
                        passed through addopts)
  --tb=style            Traceback print mode
                        (auto/long/short/line/native/no)
  --xfail-tb            Show tracebacks for xfail (as long as --tb != no)
  --show-capture={no,stdout,stderr,log,all}
                        Controls how captured stdout/stderr/log is shown on
                        failed tests. Default: all.
  --full-trace          Don't cut any tracebacks (default is to cut)
  --color=color         Color terminal output (yes/no/auto)
  --code-highlight={yes,no}
                        Whether code should be highlighted (only if --color
                        is also enabled). Default: yes.
  --pastebin=mode       Send failed|all info to bpaste.net pastebin service
  --junitxml, --junit-xml=path
                        Create junit-xml style report file at given path
  --junitprefix, --junit-prefix=str
                        Prepend prefix to classnames in junit-xml output

pytest-warnings:
  -W, --pythonwarnings PYTHONWARNINGS
                        Set which warnings to report, see -W option of
                        Python itself

collection:
  --collect-only, --co  Only collect tests, don't execute them
  --pyargs              Try to interpret all arguments as Python packages
  --ignore=path         Ignore path during collection (multi-allowed)
  --ignore-glob=path    Ignore path pattern during collection (multi-
                        allowed)
  --deselect=nodeid_prefix
                        Deselect item (via node id prefix) during collection
                        (multi-allowed)
  --confcutdir=dir      Only load conftest.py's relative to specified dir
  --noconftest          Don't load any conftest.py files
  --keep-duplicates     Keep duplicate tests
  --collect-in-virtualenv
                        Don't ignore tests in a local virtualenv directory
  --continue-on-collection-errors
                        Force test execution even if collection errors occur
  --import-mode={prepend,append,importlib}
                        Prepend/append to sys.path when importing test
                        modules and conftest files. Default: prepend.
  --doctest-modules     Run doctests in all .py modules
  --doctest-report={none,cdiff,ndiff,udiff,only_first_failure}
                        Choose another output format for diffs on doctest
                        failure
  --doctest-glob=pat    Doctests file matching pattern, default: test*.txt
  --doctest-ignore-import-errors
                        Ignore doctest collection errors
  --doctest-continue-on-failure
                        For a given doctest, continue to run after the first
                        failure

test session debugging and configuration:
  -c, --config-file FILE
                        Load configuration from `FILE` instead of trying to
                        locate one of the implicit configuration files.
  --rootdir=ROOTDIR     Define root directory for tests. Can be relative
                        path: 'root_dir', './root_dir',
                        'root_dir/another_dir/'; absolute path:
                        '/home/user/root_dir'; path with variables:
                        '$HOME/root_dir'.
  --basetemp=dir        Base temporary directory for this test run.
                        (Warning: this directory is removed if it exists.)
  -V, --version         Display pytest version and information about
                        plugins. When given twice, also display information
                        about plugins.
  -h, --help            Show help message and configuration info
  -p name               Early-load given plugin module name or entry point
                        (multi-allowed). To avoid loading of plugins, use
                        the `no:` prefix, e.g. `no:doctest`. See also
                        --disable-plugin-autoload.
  --disable-plugin-autoload
                        Disable plugin auto-loading through entry point
                        packaging metadata. Only plugins explicitly
                        specified in -p or env var PYTEST_PLUGINS will be
                        loaded.
  --trace-config        Trace considerations of conftest.py files
  --debug=[DEBUG_FILE_NAME]
                        Store internal tracing debug information in this log
                        file. This file is opened with 'w' and truncated as
                        a result, care advised. Default: pytestdebug.log.
  -o, --override-ini OVERRIDE_INI
                        Override configuration option with "option=value"
                        style, e.g. `-o strict_xfail=True -o
                        cache_dir=cache`.
  --assert=MODE         Control assertion debugging tools.
                        'plain' performs no assertion debugging.
                        'rewrite' (the default) rewrites assert statements
                        in test modules on import to provide assert
                        expression information.
  --setup-only          Only setup fixtures, do not execute tests
  --setup-show          Show setup of fixtures while executing tests
  --setup-plan          Show what fixtures and tests would be executed but
                        don't execute anything

logging:
  --log-level=LEVEL     Level of messages to catch/display. Not set by
                        default, so it depends on the root/parent log
                        handler's effective level, where it is "WARNING" by
                        default.
  --log-format=LOG_FORMAT
                        Log format used by the logging module
  --log-date-format=LOG_DATE_FORMAT
                        Log date format used by the logging module
  --log-cli-level=LOG_CLI_LEVEL
                        CLI logging level
  --log-cli-format=LOG_CLI_FORMAT
                        Log format used by the logging module
  --log-cli-date-format=LOG_CLI_DATE_FORMAT
                        Log date format used by the logging module
  --log-file=LOG_FILE   Path to a file when logging will be written to
  --log-file-mode={w,a}
                        Log file open mode
  --log-file-level=LOG_FILE_LEVEL
                        Log file logging level
  --log-file-format=LOG_FILE_FORMAT
                        Log format used by the logging module
  --log-file-date-format=LOG_FILE_DATE_FORMAT
                        Log date format used by the logging module
  --log-auto-indent=LOG_AUTO_INDENT
                        Auto-indent multiline messages passed to the logging
                        module. Accepts true|on, false|off or an integer.
  --log-disable=LOGGER_DISABLE
                        Disable a logger by name. Can be passed multiple
                        times.

[pytest] configuration options in the first pytest.toml|pytest.ini|tox.ini|setup.cfg|pyproject.toml file found:

  markers (linelist):   Register new markers for test functions
  empty_parameter_set_mark (string):
                        Default marker for empty parametersets
  strict_config (bool): Any warnings encountered while parsing the `pytest`
                        section of the configuration file raise errors
  strict_markers (bool):
                        Markers not registered in the `markers` section of
                        the configuration file raise errors
  strict (bool):        Enables all strictness options, currently:
                        strict_config, strict_markers, strict_xfail,
                        strict_parametrization_ids
  filterwarnings (linelist):
                        Each line specifies a pattern for
                        warnings.filterwarnings. Processed after
                        -W/--pythonwarnings.
  norecursedirs (args): Directory patterns to avoid for recursion
  testpaths (args):     Directories to search for tests when no files or
                        directories are given on the command line
  collect_imported_tests (bool):
                        Whether to collect tests in imported modules outside
                        `testpaths`
  consider_namespace_packages (bool):
                        Consider namespace packages when resolving module
                        names during import
  usefixtures (args):   List of default fixtures to be used with this
                        project
  python_files (args):  Glob-style file patterns for Python test module
                        discovery
  python_classes (args):
                        Prefixes or glob names for Python test class
                        discovery
  python_functions (args):
                        Prefixes or glob names for Python test function and
                        method discovery
  disable_test_id_escaping_and_forfeit_all_rights_to_community_support (bool):
                        Disable string escape non-ASCII characters, might
                        cause unwanted side effects(use at your own risk)
  strict_parametrization_ids (bool):
                        Emit an error if non-unique parameter set IDs are
                        detected
  console_output_style (string):
                        Console output: "classic", or with additional
                        progress information ("progress" (percentage) |
                        "count" | "progress-even-when-capture-no" (forces
                        progress even when capture=no)
  verbosity_test_cases (string):
                        Specify a verbosity level for test case execution,
                        overriding the main level. Higher levels will
                        provide more detailed information about each test
                        case executed.
  strict_xfail (bool):  Default for the strict parameter of xfail markers
                        when not given explicitly (default: False) (alias:
                        xfail_strict)
  tmp_path_retention_count (string):
                        How many sessions should we keep the `tmp_path`
                        directories, according to
                        `tmp_path_retention_policy`.
  tmp_path_retention_policy (string):
                        Controls which directories created by the `tmp_path`
                        fixture are kept around, based on test outcome.
                        (all/failed/none)
  enable_assertion_pass_hook (bool):
                        Enables the pytest_assertion_pass hook. Make sure to
                        delete any previously generated pyc cache files.
  truncation_limit_lines (string):
                        Set threshold of LINES after which truncation will
                        take effect
  truncation_limit_chars (string):
                        Set threshold of CHARS after which truncation will
                        take effect
  verbosity_assertions (string):
                        Specify a verbosity level for assertions, overriding
                        the main level. Higher levels will provide more
                        detailed explanation when an assertion fails.
  junit_suite_name (string):
                        Test suite name for JUnit report
  junit_logging (string):
                        Write captured log messages to JUnit report: one of
                        no|log|system-out|system-err|out-err|all
  junit_log_passing_tests (bool):
                        Capture log information for passing tests to JUnit
                        report:
  junit_duration_report (string):
                        Duration time to report: one of total|call
  junit_family (string):
                        Emit XML for schema: one of legacy|xunit1|xunit2
  doctest_optionflags (args):
                        Option flags for doctests
  doctest_encoding (string):
                        Encoding used for doctest files
  cache_dir (string):   Cache directory path
  log_level (string):   Default value for --log-level
  log_format (string):  Default value for --log-format
  log_date_format (string):
                        Default value for --log-date-format
  log_cli (bool):       Enable log display during test run (also known as
                        "live logging")
  log_cli_level (string):
                        Default value for --log-cli-level
  log_cli_format (string):
                        Default value for --log-cli-format
  log_cli_date_format (string):
                        Default value for --log-cli-date-format
  log_file (string):    Default value for --log-file
  log_file_mode (string):
                        Default value for --log-file-mode
  log_file_level (string):
                        Default value for --log-file-level
  log_file_format (string):
                        Default value for --log-file-format
  log_file_date_format (string):
                        Default value for --log-file-date-format
  log_auto_indent (string):
                        Default value for --log-auto-indent
  faulthandler_timeout (string):
                        Dump the traceback of all threads if a test takes
                        more than TIMEOUT seconds to finish
  faulthandler_exit_on_timeout (bool):
                        Exit the test process if a test takes more than
                        faulthandler_timeout seconds to finish
  verbosity_subtests (string):
                        Specify verbosity level for subtests. Higher levels
                        will generate output for passed subtests. Failed
                        subtests are always reported.
  addopts (args):       Extra command line options
  minversion (string):  Minimally required pytest version
  pythonpath (paths):   Add paths to sys.path
  required_plugins (args):
                        Plugins that must be present for pytest to run

Environment variables:
  CI                       When set to a non-empty value, pytest knows it is running in a CI process and does not truncate summary info
  BUILD_NUMBER             Equivalent to CI
  PYTEST_ADDOPTS           Extra command line options
  PYTEST_PLUGINS           Comma-separated plugins to load during startup
  PYTEST_DISABLE_PLUGIN_AUTOLOAD Set to disable plugin auto-loading
  PYTEST_DEBUG             Set to enable debug tracing of pytest's internals
  PYTEST_DEBUG_TEMPROOT    Override the system temporary directory
  PYTEST_THEME             The Pygments style to use for code output
  PYTEST_THEME_MODE        Set the PYTEST_THEME to be either 'dark' or 'light'


to see available markers type: pytest --markers
to see available fixtures type: pytest --fixtures
(shown according to specified file_or_dir or current dir if not specified; fixtures with leading '_' are only shown with the '-v' option