Grundlegende Muster und Beispiele¶
Wie man Standardwerte für Kommandozeilenoptionen ändert¶
Es kann mühsam sein, jedes Mal dieselbe Reihe von Kommandozeilenoptionen einzugeben, wenn Sie pytest verwenden. Wenn Sie beispielsweise immer detaillierte Informationen zu übersprungenen und xfailed-Tests sehen möchten und eine kürzere "Punkt"-Fortschrittsanzeige wünschen, können Sie dies in eine Konfigurationsdatei schreiben.
# content of pytest.toml
[pytest]
addopts = ["-ra", "-q"]
Alternativ können Sie die Umgebungsvariable PYTEST_ADDOPTS setzen, um Kommandozeilenoptionen hinzuzufügen, solange die Umgebung verwendet wird.
export PYTEST_ADDOPTS="-v"
So wird die Kommandozeile im Falle von addopts oder der Umgebungsvariable aufgebaut.
<configuration file addopts> $PYTEST_ADDOPTS <extra command-line arguments>
Wenn der Benutzer also in der Kommandozeile eingibt
pytest -m slow
Die tatsächlich ausgeführte Kommandozeile ist
pytest -ra -q -v -m slow
Beachten Sie, dass, wie üblich bei anderen Kommandozeilenanwendungen, im Falle von widersprüchlichen Optionen die letzte gewinnt. Das obige Beispiel zeigt also eine ausführliche Ausgabe, da -v -q überschreibt.
Unterschiedliche Werte an eine Testfunktion übergeben, abhängig von Kommandozeilenoptionen¶
Angenommen, wir möchten einen Test schreiben, der von einer Kommandozeilenoption abhängt. Hier ist ein grundlegendes Muster, um dies zu erreichen:
# content of test_sample.py
def test_answer(cmdopt):
if cmdopt == "type1":
print("first")
elif cmdopt == "type2":
print("second")
assert 0 # to see what was printed
Damit dies funktioniert, müssen wir eine Kommandozeilenoption hinzufügen und cmdopt über eine Fixture-Funktion bereitstellen.
# content of conftest.py
import pytest
def pytest_addoption(parser):
parser.addoption(
"--cmdopt", action="store", default="type1", help="my option: type1 or type2"
)
@pytest.fixture
def cmdopt(request):
return request.config.getoption("--cmdopt")
Lassen Sie uns dies ohne Angabe unserer neuen Option ausführen.
$ pytest -q test_sample.py
F [100%]
================================= FAILURES =================================
_______________________________ test_answer ________________________________
cmdopt = 'type1'
def test_answer(cmdopt):
if cmdopt == "type1":
print("first")
elif cmdopt == "type2":
print("second")
> assert 0 # to see what was printed
^^^^^^^^
E assert 0
test_sample.py:6: AssertionError
--------------------------- Captured stdout call ---------------------------
first
========================= short test summary info ==========================
FAILED test_sample.py::test_answer - assert 0
1 failed in 0.12s
Und nun mit Angabe einer Kommandozeilenoption.
$ pytest -q --cmdopt=type2
F [100%]
================================= FAILURES =================================
_______________________________ test_answer ________________________________
cmdopt = 'type2'
def test_answer(cmdopt):
if cmdopt == "type1":
print("first")
elif cmdopt == "type2":
print("second")
> assert 0 # to see what was printed
^^^^^^^^
E assert 0
test_sample.py:6: AssertionError
--------------------------- Captured stdout call ---------------------------
second
========================= short test summary info ==========================
FAILED test_sample.py::test_answer - assert 0
1 failed in 0.12s
Sie können sehen, dass die Kommandozeilenoption in unserem Test angekommen ist.
Wir könnten einfache Validierungen für die Eingabe hinzufügen, indem wir die Auswahlmöglichkeiten auflisten.
# content of conftest.py
import pytest
def pytest_addoption(parser):
parser.addoption(
"--cmdopt",
action="store",
default="type1",
help="my option: type1 or type2",
choices=("type1", "type2"),
)
Jetzt erhalten wir Feedback zu einem ungültigen Argument.
$ pytest -q --cmdopt=type3
ERROR: usage: pytest [options] [file_or_dir] [file_or_dir] [...]
pytest: error: argument --cmdopt: invalid choice: 'type3' (choose from type1, type2)
inifile: None
rootdir: /home/sweet/project
Wenn Sie detailliertere Fehlermeldungen bereitstellen müssen, können Sie den Parameter type verwenden und pytest.UsageError auslösen.
# content of conftest.py
import pytest
def type_checker(value):
msg = "cmdopt must specify a numeric type as typeNNN"
if not value.startswith("type"):
raise pytest.UsageError(msg)
try:
int(value[4:])
except ValueError:
raise pytest.UsageError(msg)
return value
def pytest_addoption(parser):
parser.addoption(
"--cmdopt",
action="store",
default="type1",
help="my option: type1 or type2",
type=type_checker,
)
Dies schließt das grundlegende Muster ab. Oft möchte man jedoch Kommandozeilenoptionen lieber außerhalb des Tests verarbeiten und stattdessen unterschiedliche oder komplexere Objekte übergeben.
Dynamisches Hinzufügen von Kommandozeilenoptionen¶
Über addopts können Sie statisch Kommandozeilenoptionen für Ihr Projekt hinzufügen. Sie können auch dynamisch Kommandozeilenargumente modifizieren, bevor sie verarbeitet werden.
# installable external plugin
import sys
def pytest_load_initial_conftests(args):
if "xdist" in sys.modules: # pytest-xdist plugin
import multiprocessing
num = max(multiprocessing.cpu_count() / 2, 1)
args[:] = ["-n", str(num)] + args
Wenn Sie das xdist-Plugin installiert haben, werden Sie nun immer Testläufe mit einer Anzahl von Unterprozessen durchführen, die Ihrer CPU nahe kommt. Ausführung in einem leeren Verzeichnis mit dem obigen conftest.py:
$ pytest
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 0 items
========================== no tests ran in 0.12s ===========================
Überspringen von Tests anhand von Kommandozeilenoptionen steuern¶
Hier ist eine conftest.py Datei, die eine --runslow Kommandozeilenoption hinzufügt, um das Überspringen von Tests mit dem Markierer pytest.mark.slow zu steuern.
# content of conftest.py
import pytest
def pytest_addoption(parser):
parser.addoption(
"--runslow", action="store_true", default=False, help="run slow tests"
)
def pytest_configure(config):
config.addinivalue_line("markers", "slow: mark test as slow to run")
def pytest_collection_modifyitems(config, items):
if config.getoption("--runslow"):
# --runslow given in cli: do not skip slow tests
return
skip_slow = pytest.mark.skip(reason="need --runslow option to run")
for item in items:
if "slow" in item.keywords:
item.add_marker(skip_slow)
Wir können nun ein Testmodul wie folgt schreiben:
# content of test_module.py
import pytest
def test_func_fast():
pass
@pytest.mark.slow
def test_func_slow():
pass
und bei der Ausführung sehen wir einen übersprungenen "slow"-Test.
$ pytest -rs # "-rs" means report details on the little 's'
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 2 items
test_module.py .s [100%]
========================= short test summary info ==========================
SKIPPED [1] test_module.py:8: need --runslow option to run
======================= 1 passed, 1 skipped in 0.12s =======================
Oder führen Sie es aus und schließen Sie den mit slow markierten Test mit ein.
$ pytest --runslow
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 2 items
test_module.py .. [100%]
============================ 2 passed in 0.12s =============================
Gut integrierte Assertionshelfer schreiben¶
Wenn Sie eine Test-Hilfsfunktion haben, die von einem Test aufgerufen wird, können Sie den pytest.fail Marker verwenden, um einen Test mit einer bestimmten Meldung fehlschlagen zu lassen. Die Test-Unterstützungsfunktion wird in der Traceback-Liste nicht angezeigt, wenn Sie die Option __tracebackhide__ irgendwo in der Hilfsfunktion setzen. Beispiel:
# content of test_checkconfig.py
import pytest
def checkconfig(x):
__tracebackhide__ = True
if not hasattr(x, "config"):
pytest.fail(f"not configured: {x}")
def test_something():
checkconfig(42)
Die Einstellung __tracebackhide__ beeinflusst die Anzeige von Tracebacks durch pytest: Die Funktion checkconfig wird nicht angezeigt, es sei denn, die Kommandozeilenoption --full-trace wird angegeben. Lassen Sie uns unsere kleine Funktion ausführen:
$ pytest -q test_checkconfig.py
F [100%]
================================= FAILURES =================================
______________________________ test_something ______________________________
def test_something():
> checkconfig(42)
E Failed: not configured: 42
test_checkconfig.py:11: Failed
========================= short test summary info ==========================
FAILED test_checkconfig.py::test_something - Failed: not configured: 42
1 failed in 0.12s
Wenn Sie nur bestimmte Ausnahmen ausblenden möchten, können Sie __tracebackhide__ auf eine aufrufbare Funktion setzen, die das ExceptionInfo Objekt erhält. Sie können dies beispielsweise verwenden, um sicherzustellen, dass unerwartete Ausnahmearten nicht ausgeblendet werden.
import operator
import pytest
class ConfigException(Exception):
pass
def checkconfig(x):
__tracebackhide__ = operator.methodcaller("errisinstance", ConfigException)
if not hasattr(x, "config"):
raise ConfigException(f"not configured: {x}")
def test_something():
checkconfig(42)
Dies vermeidet das Ausblenden des Ausnahme-Tracebacks bei unerheblichen Ausnahmen (d.h. Fehlern in den Assertionshelfern).
Erkennen, ob aus einem pytest-Lauf heraus ausgeführt wird¶
Normalerweise ist es keine gute Idee, Anwendungs-Code anders zu verhalten lassen, wenn er von einem Test aufgerufen wird. Wenn Sie jedoch unbedingt feststellen müssen, ob Ihr Anwendungs-Code von einem Test aus ausgeführt wird, können Sie dies tun:
import os
if os.environ.get("PYTEST_VERSION") is not None:
# Things you want to to do if your code is called by pytest.
...
else:
# Things you want to to do if your code is not called by pytest.
...
Informationen zum Testbericht-Header hinzufügen¶
Es ist einfach, zusätzliche Informationen in einem pytest-Lauf darzustellen.
# content of conftest.py
def pytest_report_header(config):
return "project deps: mylib-1.1"
was die Zeichenkette entsprechend zum Test-Header hinzufügt.
$ pytest
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
project deps: mylib-1.1
rootdir: /home/sweet/project
collected 0 items
========================== no tests ran in 0.12s ===========================
Es ist auch möglich, eine Liste von Zeichenketten zurückzugeben, die als mehrere Informationszeilen betrachtet werden. Sie können config.getoption('verbose') berücksichtigen, um bei Bedarf mehr Informationen anzuzeigen.
# content of conftest.py
def pytest_report_header(config):
if config.get_verbosity() > 0:
return ["info1: did you know that ...", "did you?"]
was Informationen hinzufügt, nur wenn mit "–v" ausgeführt.
$ pytest -v
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y -- $PYTHON_PREFIX/bin/python
cachedir: .pytest_cache
info1: did you know that ...
did you?
rootdir: /home/sweet/project
collecting ... collected 0 items
========================== no tests ran in 0.12s ===========================
und nichts, wenn normal ausgeführt.
$ pytest
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 0 items
========================== no tests ran in 0.12s ===========================
Profiling der Testdauer¶
Wenn Sie eine langsam laufende große Testsuite haben, möchten Sie vielleicht herausfinden, welche Tests am langsamsten sind. Machen wir eine künstliche Testsuite:
# content of test_some_are_slow.py
import time
def test_funcfast():
time.sleep(0.1)
def test_funcslow1():
time.sleep(0.2)
def test_funcslow2():
time.sleep(0.3)
Nun können wir profilieren, welche Testfunktionen am langsamsten ausgeführt werden.
$ pytest --durations=3
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 3 items
test_some_are_slow.py ... [100%]
=========================== slowest 3 durations ============================
0.30s call test_some_are_slow.py::test_funcslow2
0.20s call test_some_are_slow.py::test_funcslow1
0.10s call test_some_are_slow.py::test_funcfast
============================ 3 passed in 0.12s =============================
Inkrementelles Testen - Testschritte¶
Manchmal haben Sie eine Testsituation, die aus einer Reihe von Testschritten besteht. Wenn ein Schritt fehlschlägt, macht es keinen Sinn, weitere Schritte auszuführen, da diese alle voraussichtlich fehlschlagen werden und ihre Tracebacks keine zusätzlichen Erkenntnisse liefern. Hier ist eine einfache conftest.py-Datei, die einen incremental-Marker einführt, der auf Klassen angewendet werden soll.
# content of conftest.py
from typing import Dict, Tuple
import pytest
# store history of failures per test class name and per index in parametrize (if parametrize used)
_test_failed_incremental: Dict[str, Dict[Tuple[int, ...], str]] = {}
def pytest_runtest_makereport(item, call):
if "incremental" in item.keywords:
# incremental marker is used
if call.excinfo is not None:
# the test has failed
# retrieve the class name of the test
cls_name = str(item.cls)
# retrieve the index of the test (if parametrize is used in combination with incremental)
parametrize_index = (
tuple(item.callspec.indices.values())
if hasattr(item, "callspec")
else ()
)
# retrieve the name of the test function
test_name = item.originalname or item.name
# store in _test_failed_incremental the original name of the failed test
_test_failed_incremental.setdefault(cls_name, {}).setdefault(
parametrize_index, test_name
)
def pytest_runtest_setup(item):
if "incremental" in item.keywords:
# retrieve the class name of the test
cls_name = str(item.cls)
# check if a previous test has failed for this class
if cls_name in _test_failed_incremental:
# retrieve the index of the test (if parametrize is used in combination with incremental)
parametrize_index = (
tuple(item.callspec.indices.values())
if hasattr(item, "callspec")
else ()
)
# retrieve the name of the first test function to fail for this class name and index
test_name = _test_failed_incremental[cls_name].get(parametrize_index, None)
# if name found, test has failed for the combination of class name & test name
if test_name is not None:
pytest.xfail(f"previous test failed ({test_name})")
Diese beiden Hook-Implementierungen arbeiten zusammen, um inkrementell markierte Tests in einer Klasse abzubrechen. Hier ist ein Beispiel für ein Testmodul:
# content of test_step.py
import pytest
@pytest.mark.incremental
class TestUserHandling:
def test_login(self):
pass
def test_modification(self):
assert 0
def test_deletion(self):
pass
def test_normal():
pass
Wenn wir dies ausführen:
$ pytest -rx
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 4 items
test_step.py .Fx. [100%]
================================= FAILURES =================================
____________________ TestUserHandling.test_modification ____________________
self = <test_step.TestUserHandling object at 0xdeadbeef0001>
def test_modification(self):
> assert 0
E assert 0
test_step.py:11: AssertionError
========================= short test summary info ==========================
XFAIL test_step.py::TestUserHandling::test_deletion - previous test failed (test_modification)
================== 1 failed, 2 passed, 1 xfailed in 0.12s ==================
Wir werden sehen, dass test_deletion nicht ausgeführt wurde, weil test_modification fehlgeschlagen ist. Dies wird als "erwartetes Fehlschlagen" gemeldet.
Paket-/Verzeichnisebene-Fixtures (Setups)¶
Wenn Sie verschachtelte Testverzeichnisse haben, können Sie Fixture-Scopes pro Verzeichnis haben, indem Sie Fixture-Funktionen in einer conftest.py-Datei in diesem Verzeichnis platzieren. Sie können alle Arten von Fixtures verwenden, einschließlich autouse Fixtures, die das Äquivalent zu xUnits Setup/Teardown-Konzept sind. Es wird jedoch empfohlen, explizite Fixture-Referenzen in Ihren Tests oder Testklassen zu haben, anstatt sich auf implizit ausgeführte Setup/Teardown-Funktionen zu verlassen, insbesondere wenn diese weit von den eigentlichen Tests entfernt sind.
Hier ist ein Beispiel, um eine db-Fixture in einem Verzeichnis verfügbar zu machen.
# content of a/conftest.py
import pytest
class DB:
pass
@pytest.fixture(scope="package")
def db():
return DB()
und dann ein Testmodul in diesem Verzeichnis:
# content of a/test_db.py
def test_a1(db):
assert 0, db # to show value
ein weiteres Testmodul:
# content of a/test_db2.py
def test_a2(db):
assert 0, db # to show value
und dann ein Modul in einem Schwesterverzeichnis, das die db-Fixture nicht sieht.
# content of b/test_error.py
def test_root(db): # no db here, will error out
pass
Wir können dies ausführen:
$ pytest
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 7 items
a/test_db.py F [ 14%]
a/test_db2.py F [ 28%]
b/test_error.py E [ 42%]
test_step.py .Fx. [100%]
================================== ERRORS ==================================
_______________________ ERROR at setup of test_root ________________________
file /home/sweet/project/b/test_error.py, line 1
def test_root(db): # no db here, will error out
E fixture 'db' not found
> available fixtures: cache, capfd, capfdbinary, caplog, capsys, capsysbinary, capteesys, doctest_namespace, monkeypatch, pytestconfig, record_property, record_testsuite_property, record_xml_attribute, recwarn, subtests, tmp_path, tmp_path_factory, tmpdir, tmpdir_factory
> use 'pytest --fixtures [testpath]' for help on them.
/home/sweet/project/b/test_error.py:1
================================= FAILURES =================================
_________________________________ test_a1 __________________________________
db = <conftest.DB object at 0xdeadbeef0002>
def test_a1(db):
> assert 0, db # to show value
^^^^^^^^^^^^
E AssertionError: <conftest.DB object at 0xdeadbeef0002>
E assert 0
a/test_db.py:2: AssertionError
_________________________________ test_a2 __________________________________
db = <conftest.DB object at 0xdeadbeef0002>
def test_a2(db):
> assert 0, db # to show value
^^^^^^^^^^^^
E AssertionError: <conftest.DB object at 0xdeadbeef0002>
E assert 0
a/test_db2.py:2: AssertionError
____________________ TestUserHandling.test_modification ____________________
self = <test_step.TestUserHandling object at 0xdeadbeef0003>
def test_modification(self):
> assert 0
E assert 0
test_step.py:11: AssertionError
========================= short test summary info ==========================
FAILED a/test_db.py::test_a1 - AssertionError: <conftest.DB object at 0x7...
FAILED a/test_db2.py::test_a2 - AssertionError: <conftest.DB object at 0x...
FAILED test_step.py::TestUserHandling::test_modification - assert 0
ERROR b/test_error.py::test_root
============= 3 failed, 2 passed, 1 xfailed, 1 error in 0.12s ==============
Die beiden Testmodule im Verzeichnis a sehen dieselbe db-Fixture-Instanz, während das eine Testmodul im Schwesterverzeichnis b es nicht sieht. Wir könnten natürlich auch eine db-Fixture in der conftest.py-Datei dieses Schwesterverzeichnisses definieren. Beachten Sie, dass jede Fixture nur instanziiert wird, wenn ein Test sie tatsächlich benötigt (es sei denn, Sie verwenden "autouse"-Fixtures, die immer vor dem ersten Test ausgeführt werden).
Testberichte / Fehler nachverarbeiten¶
Wenn Sie Testberichte nachverarbeiten möchten und Zugriff auf die ausführende Umgebung benötigen, können Sie einen Hook implementieren, der aufgerufen wird, wenn das "report"-Objekt des Tests erstellt wird. Hier schreiben wir alle fehlschlagenden Testaufrufe aus und greifen auch auf eine Fixture zu (falls sie vom Test verwendet wurde), falls Sie sie während der Nachbearbeitung abfragen/anschauen möchten. In unserem Fall schreiben wir nur einige Informationen in eine failures-Datei.
# content of conftest.py
import os.path
import pytest
@pytest.hookimpl(wrapper=True, tryfirst=True)
def pytest_runtest_makereport(item, call):
# execute all other hooks to obtain the report object
rep = yield
# we only look at actual failing test calls, not setup/teardown
if rep.when == "call" and rep.failed:
mode = "a" if os.path.exists("failures") else "w"
with open("failures", mode, encoding="utf-8") as f:
# let's also access a fixture for the fun of it
if "tmp_path" in item.fixturenames:
extra = " ({})".format(item.funcargs["tmp_path"])
else:
extra = ""
f.write(rep.nodeid + extra + "\n")
return rep
Wenn Sie dann fehlschlagende Tests haben:
# content of test_module.py
def test_fail1(tmp_path):
assert 0
def test_fail2():
assert 0
und sie ausführen:
$ pytest test_module.py
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 2 items
test_module.py FF [100%]
================================= FAILURES =================================
________________________________ test_fail1 ________________________________
tmp_path = PosixPath('PYTEST_TMPDIR/test_fail10')
def test_fail1(tmp_path):
> assert 0
E assert 0
test_module.py:2: AssertionError
________________________________ test_fail2 ________________________________
def test_fail2():
> assert 0
E assert 0
test_module.py:6: AssertionError
========================= short test summary info ==========================
FAILED test_module.py::test_fail1 - assert 0
FAILED test_module.py::test_fail2 - assert 0
============================ 2 failed in 0.12s =============================
erhalten Sie eine "failures"-Datei, die die fehlschlagenden Test-IDs enthält.
$ cat failures
test_module.py::test_fail1 (PYTEST_TMPDIR/test_fail10)
test_module.py::test_fail2
Test-Ergebnisinformationen in Fixtures verfügbar machen¶
Wenn Sie Test-Ergebnisberichte in Fixture-Finalizern verfügbar machen möchten, hier ist ein kleines Beispiel, das über ein lokales Plugin implementiert wird:
# content of conftest.py
from typing import Dict
import pytest
from pytest import StashKey, CollectReport
phase_report_key = StashKey[Dict[str, CollectReport]]()
@pytest.hookimpl(wrapper=True, tryfirst=True)
def pytest_runtest_makereport(item, call):
# execute all other hooks to obtain the report object
rep = yield
# store test results for each phase of a call, which can
# be "setup", "call", "teardown"
item.stash.setdefault(phase_report_key, {})[rep.when] = rep
return rep
@pytest.fixture
def something(request):
yield
# request.node is an "item" because we use the default
# "function" scope
report = request.node.stash[phase_report_key]
if report["setup"].failed:
print("setting up a test failed", request.node.nodeid)
elif report["setup"].skipped:
print("setting up a test skipped", request.node.nodeid)
elif ("call" not in report) or report["call"].failed:
print("executing test failed or skipped", request.node.nodeid)
Wenn Sie dann fehlschlagende Tests haben:
# content of test_module.py
import pytest
@pytest.fixture
def other():
assert 0
def test_setup_fails(something, other):
pass
def test_call_fails(something):
assert 0
def test_fail2():
assert 0
und es ausführen:
$ pytest -s test_module.py
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 3 items
test_module.py Esetting up a test failed test_module.py::test_setup_fails
Fexecuting test failed or skipped test_module.py::test_call_fails
F
================================== ERRORS ==================================
____________________ ERROR at setup of test_setup_fails ____________________
@pytest.fixture
def other():
> assert 0
E assert 0
test_module.py:7: AssertionError
================================= FAILURES =================================
_____________________________ test_call_fails ______________________________
something = None
def test_call_fails(something):
> assert 0
E assert 0
test_module.py:15: AssertionError
________________________________ test_fail2 ________________________________
def test_fail2():
> assert 0
E assert 0
test_module.py:19: AssertionError
========================= short test summary info ==========================
FAILED test_module.py::test_call_fails - assert 0
FAILED test_module.py::test_fail2 - assert 0
ERROR test_module.py::test_setup_fails - assert 0
======================== 2 failed, 1 error in 0.12s ========================
Sie werden sehen, dass die Fixture-Finalizer die präzisen Berichtsinformationen nutzen konnten.
Umgebungsvariable PYTEST_CURRENT_TEST¶
Manchmal kann eine Testsitzung stecken bleiben und es gibt keine einfache Möglichkeit herauszufinden, welcher Test stecken geblieben ist, zum Beispiel wenn pytest im leisen Modus (-q) ausgeführt wurde oder Sie keinen Zugriff auf die Konsolenausgabe haben. Dies ist besonders problematisch, wenn das Problem nur sporadisch auftritt, die berühmten "flaky" Tests.
pytest setzt die Umgebungsvariable PYTEST_CURRENT_TEST beim Ausführen von Tests, die von Prozessüberwachungs-Utilities oder Bibliotheken wie psutil inspiziert werden kann, um bei Bedarf herauszufinden, welcher Test stecken geblieben ist.
import psutil
for pid in psutil.pids():
environ = psutil.Process(pid).environ()
if "PYTEST_CURRENT_TEST" in environ:
print(f'pytest process {pid} running: {environ["PYTEST_CURRENT_TEST"]}')
Während der Testsitzung setzt pytest PYTEST_CURRENT_TEST auf die aktuelle Test-nodeid und die aktuelle Phase, die setup, call oder teardown sein kann.
Wenn beispielsweise eine einzelne Testfunktion namens test_foo aus foo_module.py ausgeführt wird, wird PYTEST_CURRENT_TEST gesetzt auf:
foo_module.py::test_foo (setup)foo_module.py::test_foo (call)foo_module.py::test_foo (teardown)
In dieser Reihenfolge.
Hinweis
Der Inhalt von PYTEST_CURRENT_TEST ist für Menschen lesbar und das tatsächliche Format kann zwischen Veröffentlichungen (sogar Bugfixes) geändert werden, daher sollte er nicht für Skripte oder Automatisierung verwendet werden.
Pytest einfrieren¶
Wenn Sie Ihre Anwendung mit einem Tool wie PyInstaller einfrieren, um sie an Ihre Endbenutzer zu verteilen, ist es eine gute Idee, auch Ihren Test-Runner zu verpacken und Ihre Tests mit der eingefrorenen Anwendung auszuführen. Auf diese Weise können Verpackungsfehler, wie z.B. nicht in die ausführbare Datei aufgenommene Abhängigkeiten, frühzeitig erkannt werden, und Sie können Testdateien an Benutzer senden, damit diese sie auf ihren Maschinen ausführen können, was nützlich sein kann, um mehr Informationen über einen schwer reproduzierbaren Fehler zu erhalten.
Glücklicherweise haben neuere PyInstaller-Versionen bereits einen benutzerdefinierten Hook für pytest, aber wenn Sie ein anderes Werkzeug zum Einfrieren von ausführbaren Dateien wie cx_freeze oder py2exe verwenden, können Sie pytest.freeze_includes() verwenden, um die vollständige Liste der internen pytest-Module zu erhalten. Wie die Werkzeuge konfiguriert werden müssen, um die internen Module zu finden, variiert jedoch von Werkzeug zu Werkzeug.
Anstatt den pytest-Runner als separate ausführbare Datei einzufrieren, können Sie Ihr eingefrorenes Programm beim Programmstart durch geschicktes Argument-Handling zum pytest-Runner machen. Dies ermöglicht Ihnen eine einzige ausführbare Datei, was normalerweise bequemer ist. Beachten Sie, dass der Mechanismus zur Plugin-Erkennung, der von pytest verwendet wird (Entry Points), mit eingefrorenen ausführbaren Dateien nicht funktioniert, daher kann pytest keine Drittanbieter-Plugins automatisch finden. Um Drittanbieter-Plugins wie pytest-timeout einzubinden, müssen diese explizit importiert und an pytest.main übergeben werden.
# contents of app_main.py
import sys
import pytest_timeout # Third party plugin
if len(sys.argv) > 1 and sys.argv[1] == "--pytest":
import pytest
sys.exit(pytest.main(sys.argv[2:], plugins=[pytest_timeout]))
else:
# normal application execution: at this point argv can be parsed
# by your argument-parsing library of choice as usual
...
Dies ermöglicht es Ihnen, Tests mit der eingefrorenen Anwendung mit Standard-Kommandozeilenoptionen von pytest auszuführen.
./app_main --pytest --verbose --tb=long --junit=xml=results.xml test-suite/