pytest-Fixtures, Parametrisierung und Marker: eine Testsuite schnell und lesbar halten

Worum es geht

Eine Fixture ist eine mit @pytest.fixture dekorierte Funktion, deren zurückgegebener oder per yield gelieferter Wert in jeden Test injiziert wird, der sie als Parameter benennt; Code nach yield läuft als Teardown. Fixtures können andere Fixtures anfordern, haben einen Scope (standardmässig function, oder class, module, package, session), können autouse sein und werden über conftest.py dateiübergreifend geteilt. @pytest.mark.parametrize("a,expected", [...]) führt eine Funktion einmal pro Fall aus, jeder Fall wird separat gemeldet; pytest.param(..., marks=pytest.mark.xfail) kennzeichnet einen einzelnen Fall. Marker wie slow kennzeichnen Tests für die Auswahl mit -m "not slow"; sie werden in der Konfigurationsdatei registriert, und --strict-markers macht einen nicht registrierten Marker zu einem Fehler.

Warum es wichtig ist

Fixtures ersetzen kopierten Setup-Code und setUp-Vererbung durch Abhängigkeiten, die in der Testsignatur sichtbar sind. Parametrisierung verwandelt eine Schleife innerhalb eines Tests, die beim ersten Fehlschlag stoppt, in unabhängige Fälle. Marker erlauben es, dass ein Pull-Request-Lauf langsame Suiten überspringt, ohne Code zu ändern.

So wird es angewendet

• Standardmässig beim function-Scope bleiben; nur bei teuren, unveränderlichen Ressourcen (ein Datenbank-Container, ein kompiliertes Modell) auf module oder session erweitern. Das Beispiel der Dokumentation ist eine innerhalb eines Moduls wiederverwendete SMTP-Verbindung. Eine erweiterte Fixture niemals innerhalb eines Tests verändern.
• Eine Fixture in die nächstgelegene conftest.py legen, die alle ihre Nutzenden abdeckt; eine Root-conftest.py, die alles enthält, verschleiert, welche Tests was benötigen.
• yield-Fixtures für das Teardown verwenden, die dokumentierte empfohlene Form, damit die Aufräumarbeiten auch bei einem fehlschlagenden Test laufen.
• Parametrisierten Fällen lesbare IDs geben, damit die Auswahl mit -k und die Fehlerausgabe den Fall benennen; eine Tabelle mit Eingaben und erwarteten Ausgaben vielen nahezu identischen Funktionen vorziehen.
• Jeden Marker mit einer Beschreibung registrieren und --strict-markers zu addopts hinzufügen, damit @pytest.mark.slwo die Collection scheitern lässt, statt stillschweigend zu laufen.
• Die eingebauten Fixtures tmp_path und monkeypatch anstelle von handgeschriebenen temporären Verzeichnissen und Attribut-Patching verwenden.

Stolpersteine

Autouse-Fixtures verschleiern Abhängigkeiten; sie sollten wirklich globalen Belangen wie einer fixierten Uhr vorbehalten bleiben. Parametrize-Listen zur Importzeit aus dem Netzwerk oder einer Datenbank aufzubauen macht die Collection langsam und instabil. Eine Fixture mit weiterem Scope kann nicht von einer mit engerem Scope abhängen. Die Dokumentation hält fest, dass Marker nur auf Tests wirken und keine Auswirkung auf Fixtures haben.