Geekly articles weekly

Python-Test mit Pytest. Konfiguration, KAPITEL 6

ZurĂŒck Weiter


In diesem Kapitel werden wir uns die Konfigurationsdateien ansehen, die sich auf pytest auswirken, diskutieren, wie pytest sein Verhalten basierend auf ihnen Ă€ndert, und einige Änderungen an den Konfigurationsdateien des Aufgabenprojekts vornehmen.



Die Beispiele in diesem Buch wurden mit Python 3.6 und pytest 3.2 geschrieben. pytest 3.2 unterstĂŒtzt Python 2.6, 2.7 und Python 3.3+.


Der Quellcode fĂŒr das Aufgabenprojekt sowie fĂŒr alle in diesem Buch gezeigten Tests ist unter dem Link auf der Webseite des Buches unter pragprog.com verfĂŒgbar . Sie mĂŒssen den Quellcode nicht herunterladen, um den Testcode zu verstehen. Der Testcode wird in den Beispielen in einer praktischen Form dargestellt. Um jedoch die Aufgaben des Projekts zu verfolgen oder Testbeispiele anzupassen, um Ihr eigenes Projekt zu testen (Ihre HĂ€nde sind losgebunden!), MĂŒssen Sie auf die Webseite des Buches gehen und die Arbeit herunterladen. Dort, auf der Webseite des Buches, gibt es einen Link fĂŒr Errata- Nachrichten und ein Diskussionsforum .

Unter dem Spoiler befindet sich eine Liste der Artikel dieser Reihe.


Inhaltsverzeichnis

Konfiguration


Bisher habe ich in diesem Buch ĂŒber verschiedene Nicht-Test-Dateien gesprochen, die sich hauptsĂ€chlich nebenbei auf pytest auswirken, mit Ausnahme von conftest.py, auf das ich in Kapitel 5, Plugins, auf Seite 95 ausfĂŒhrlich eingegangen bin. In diesem Kapitel werden wir uns die Konfigurationsdateien ansehen. Dies wirkt sich auf pytest aus. Besprechen Sie, wie pytest sein Verhalten basierend darauf Ă€ndert, und nehmen Sie einige Änderungen an den Konfigurationsdateien des Aufgabenprojekts vor.


Grundlegendes zu Pytest-Konfigurationsdateien


Bevor ich Ihnen erklĂ€re, wie Sie das Standardverhalten in pytest Ă€ndern können, gehen wir alle Nicht-Testdateien in pytest durch und insbesondere, wer sich um sie kĂŒmmern sollte.


Sie sollten Folgendes wissen:


  • pytest.ini : Dies ist die Hauptkonfigurationsdatei von Pytest, mit der Sie das Standardverhalten Ă€ndern können. Da Sie einige KonfigurationsĂ€nderungen vornehmen können, ist der grĂ¶ĂŸte Teil dieses Kapitels den Einstellungen gewidmet, die Sie in pytest.ini .
  • conftest.py : Dies ist ein lokales Plugin, mit dem Hook-Funktionen und Fixtures mit dem Verzeichnis verbunden werden können, in dem die Datei conftest.py sowie mit allen Unterverzeichnissen. Die Datei conftest.py in Kapitel 5 „Plugins“ auf Seite 95 beschrieben.
  • __init__.py : Wenn diese Datei in jedes Test-Unterverzeichnis gestellt wird, können Sie identische Testdateinamen in mehreren __init__.py haben. Ein Beispiel dafĂŒr, was ohne __init__.py Dateien in __init__.py schief gehen wĂŒrde, finden __init__.py im Artikel „Vermeiden von Dateinamenkollisionen“ auf Seite 120.

Wenn Sie Tox verwenden, interessieren Sie sich fĂŒr:


  • tox.ini : Diese Datei Ă€hnelt pytest.ini , ist jedoch fĂŒr tox . Sie können hier jedoch Ihre pytest Konfiguration pytest anstatt sowohl die tox.ini Datei als auch die pytest.ini Datei zu haben, wodurch Sie eine Konfigurationsdatei speichern. Tox wird in Kapitel 7, „Verwenden von Pytest mit anderen Tools“, auf Seite 125 erlĂ€utert.

Wenn Sie ein Python-Paket (z. B. Aufgaben) verteilen möchten, ist diese Datei von Interesse:


  • setup.cfg : Dies ist auch eine INI-Datei, die das Verhalten von setup.py . Sie können setup.py einige Zeilen setup.py , um python setup.py test und alle Ihre pytest-Tests auszufĂŒhren. Wenn Sie das Paket verteilen, verfĂŒgen Sie möglicherweise bereits ĂŒber die Datei setup.cfg und können diese Datei zum Speichern der Pytest-Konfiguration verwenden. Wie das geht, erfahren Sie in Anhang 4, „Packen und Verteilen von Python-Projekten“, auf Seite 175.

UnabhĂ€ngig davon, in welche Datei Sie die Pytest-Konfiguration einfĂŒgen, ist das Format im Wesentlichen dasselbe.


FĂŒr pytest.ini :


ch6 / format / pytest.ini

 [pytest] addopts = -rsxX -l --tb=short --strict xfail_strict = true ... more options ...

FĂŒr tox.ini :


ch6 / format / tox.ini

 ... tox specific stuff ... [pytest] addopts = -rsxX -l --tb=short --strict xfail_strict = true ... more options ...

FĂŒr setup.cfg :


ch6 / format / setup.cfg

 ... packaging specific stuff ... [tool:pytest] addopts = -rsxX -l --tb=short --strict xfail_strict = true ... more options ...

Der einzige Unterschied besteht darin, dass der Abschnittskopf fĂŒr setup.cfg [tool:pytest] anstelle von [pytest] .


Listen Sie die gĂŒltigen INI-Datei-Optionen mit pytest –help auf


Eine Liste aller gĂŒltigen Parameter fĂŒr pytest.ini von pytest --help :


 $ pytest --help ... [pytest] ini-options in the first pytest.ini|tox.ini|setup.cfg file found: markers (linelist) markers for test functions empty_parameter_set_mark (string) default marker for empty parametersets norecursedirs (args) directory patterns to avoid for recursion testpaths (args) directories to search for tests when no files or directories are given in the command line. console_output_style (string) console output: classic or with additional progress information (classic|progress). 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 xfail_strict (bool) default for the strict parameter of xfail markers when not given explicitly (default: False) junit_suite_name (string) Test suite name for JUnit report junit_logging (string) Write captured log messages to JUnit report: one of no|system-out|system-err doctest_optionflags (args) option flags for doctests doctest_encoding (string) encoding used for doctest files cache_dir (string) cache directory path. filterwarnings (linelist) Each line specifies a pattern for warnings.filterwarnings. Processed after -W and --pythonwarnings. log_print (bool) default value for --no-print-logs 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_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 addopts (args) extra command line options minversion (string) minimally required pytest version xvfb_width (string) Width of the Xvfb display xvfb_height (string) Height of the Xvfb display xvfb_colordepth (string) Color depth of the Xvfb display xvfb_args (args) Additional arguments for Xvfb xvfb_xauth (bool) Generate an Xauthority token for Xvfb. Needs xauth. ...

Alle diese Einstellungen werden in diesem Kapitel doctest_optionflags , mit Ausnahme der doctest_optionflags , die in Kapitel 7, „Verwenden von pytest mit anderen Tools“, auf Seite 125 erlĂ€utert werden.


Plugins können INI-Dateioptionen hinzufĂŒgen


Die vorherige Liste der Einstellungen ist keine Konstante. FĂŒr Plugins (und conftest.py-Dateien) können INI-Dateioptionen hinzugefĂŒgt werden. HinzugefĂŒgte Optionen werden auch zur Ausgabe des Befehls pytest --help hinzugefĂŒgt.
Schauen wir uns nun einige KonfigurationsĂ€nderungen an, die wir mithilfe der integrierten Einstellungen der INI-Datei vornehmen können, die in Core Pytest verfĂŒgbar sind.


Ändern Sie die Standardbefehlszeilenoptionen


Sie haben bereits einige Befehlszeilenoptionen fĂŒr pytest verwendet , z. B. -v/--verbose fĂŒr die ausfĂŒhrliche Ausgabe -l/--showlocals , um lokale Variablen mit einem Stack-Trace fĂŒr fehlgeschlagene Tests -l/--showlocals . Möglicherweise verwenden Sie einige dieser options—or bevorzugen them—for a project . Wenn Sie in pytest.ini fĂŒr die benötigten Parameter installieren, mĂŒssen Sie diese nicht mehr eingeben. Hier ist ein Set, das mir gefĂ€llt:


 [pytest] addopts = -rsxX -l --tb=short --strict

Mit -rsxX kann pytest die GrĂŒnde fĂŒr alle skipped , xfailed oder nicht xpassed Tests xpassed . Mit dem Schalter -l kann pytest bei jedem Fehler eine Stapelverfolgung fĂŒr lokale Variablen anzeigen. --tb=short entfernt den grĂ¶ĂŸten Teil der Stapelverfolgung. Die Datei und die Zeilennummer bleiben jedoch erhalten. Die --strict verbietet die Verwendung von Token, wenn diese nicht in der Konfigurationsdatei registriert sind. Wie das geht, erfahren Sie im nĂ€chsten Abschnitt.


Markerregistrierung, um Tippfehler zu vermeiden


Benutzerdefinierte Markierungen, wie unter „Beschriften von Testfunktionen“ auf Seite 31 beschrieben, eignen sich hervorragend, um eine Teilmenge von Tests zu markieren, die mit einer bestimmten Markierung ausgefĂŒhrt werden sollen. Es ist jedoch zu einfach, einen Fehler in der Markierung zu machen, und letztendlich sind einige Tests mit @pytest.mark.smoke und einige mit @pytest.mark.somke . StandardmĂ€ĂŸig ist dies kein Fehler. pytest glaubt nur, dass Sie zwei Marker erstellt haben. Dies kann jedoch behoben werden, indem Token in pytest.ini registriert werden, beispielsweise wie folgt:


 [pytest] ... markers = smoke: Run the smoke test test functions get: Run the test functions that test tasks.get() ...

Wenn Sie diese Marker registrieren, können Sie sie jetzt auch mit pytest --markers mit ihren Beschreibungen pytest --markers :


 $ cd /path/to/code/ch6/b/tasks_proj/tests $ pytest --markers @pytest.mark.smoke: Run the smoke test test functions @pytest.mark.get: Run the test functions that test tasks.get() @pytest.mark.skip(reason=None): skip the ... ...

Wenn Marker nicht registriert sind, werden sie nicht in der Liste --markers . Wenn sie registriert sind, werden sie in der Liste angezeigt. Wenn Sie --strict , werden alle fehlerhaften oder nicht registrierten Token als Fehler angezeigt. Der einzige Unterschied zwischen ch6/a/tasks_proj und ch6/b/tasks_proj ist der Inhalt der Datei pytest.ini. In ch6/a leer. Versuchen wir, die Tests auszufĂŒhren, ohne Marker zu registrieren:


 $ cd /path/to/code/ch6/a/tasks_proj/tests $ pytest --strict --tb=line ============================= test session starts ============================= collected 45 items / 2 errors =================================== ERRORS ==================================== ______________________ ERROR collecting func/test_add.py ______________________ 'smoke' not a registered marker ________________ ERROR collecting func/test_api_exceptions.py _________________ 'smoke' not a registered marker !!!!!!!!!!!!!!!!!!! Interrupted: 2 errors during collection !!!!!!!!!!!!!!!!!!! =========================== 2 error in 1.10 seconds ===========================

Wenn Sie Marker in pytest.ini , um Ihre Marker zu registrieren, können Sie Ihren addopts auch --strict addopts wĂ€hrend Sie gerade dabei sind. Du wirst mir spĂ€ter danken. Lassen Sie uns fortfahren und dem Aufgabenprojekt eine pytest.ini-Datei hinzufĂŒgen:


Wenn Sie Marker in pytest.ini , um Ihre Marker zu registrieren, können --strict Ihren addopts auch --strict addopts . Du wirst mir spĂ€ter danken. Fahren wir fort und fĂŒgen die Datei pytest.ini zum Aufgabenprojekt hinzu:


Wenn Sie Token in pytest.ini , um Token zu registrieren, können Sie auch --strict zu vorhandenen Token mit addopts . Cool ?! pytest.ini Sie den Dank pytest.ini und fĂŒgen Sie die Datei pytest.ini zum tasks :


ch6 / b / task_proj / tests / pytest.ini

 [pytest] addopts = -rsxX -l --tb=short --strict markers = smoke: Run the smoke test test functions get: Run the test functions that test tasks.get()

Hier ist die standardmĂ€ĂŸig bevorzugte Kombination von Flags:


  • -rsxX um -rsxX welche Tests ĂŒbersprungen, fehlgeschlagen oder bestanden wurden.
  • --tb = short fĂŒr eine kĂŒrzere Ablaufverfolgung bei Fehlern,
  • --strict , um nur deklarierte Token zuzulassen.
    Und eine Liste von Markern fĂŒr das Projekt.

Dies sollte es uns ermöglichen, Tests durchzufĂŒhren, einschließlich Rauchtests:


 $ cd /path/to/code/ch6/b/tasks_proj/tests $ pytest --strict -m smoke ===================== test session starts ====================== collected 57 items func/test_add.py . func/test_api_exceptions.py .. ===================== 54 tests deselected ====================== =========== 3 passed, 54 deselected in 0.06 seconds ============

Mindestanforderung an Pytest


Mit minversion Parameter minversion können minversion die minimale Pytest-Version angeben, die fĂŒr Tests erwartet wird. Zum Beispiel wollte ich beim Testen von Gleitkommazahlen approx() verwenden, um die „ziemlich enge“ Gleichheit in Tests zu bestimmen. Diese Funktion wurde jedoch erst in Version 3.0 in pytest eingefĂŒhrt. Um Verwirrung zu vermeiden, fĂŒge ich Projekten, die approx() Folgendes hinzu:


 [pytest] minversion = 3.0

Wenn also jemand versucht, Tests mit einer Ă€lteren Version von pytest auszufĂŒhren, wird eine Fehlermeldung angezeigt.


Verhindern Sie, dass Pytest an den falschen Stellen sucht


Wussten Sie, dass eine der Definitionen von „Rekurs“ darin besteht, zweimal in Ihrem eigenen Code zu schwören? Nun, nein. In der Tat bedeutet dies die BerĂŒcksichtigung von Unterverzeichnissen. pytest ermöglicht die Testerkennung durch rekursives Untersuchen einer Reihe von Verzeichnissen. Es gibt jedoch einige Verzeichnisse, die Sie vom Anzeigen von pytest ausschließen möchten.


Der Standardwert fĂŒr norecurse ist '. * Build dist CVS _darcs {arch} and *.egg. Having '.*' '. * Build dist CVS _darcs {arch} and *.egg. Having '.*' '. * Build dist CVS _darcs {arch} and *.egg. Having '.*' Ist ein guter Grund, Ihre virtuelle Umgebung '.venv' zu nennen, da nicht alle Verzeichnisse, die mit einem Punkt beginnen, sichtbar sind.


Im Fall des Tasks-Projekts schadet es nicht, src anzugeben, da das Suchen in Testdateien mit pytest Zeitverschwendung ist.


 [pytest] norecursedirs = .* venv src *.egg dist build

Wenn Sie einen Parameter ĂŒberschreiben, der bereits einen nĂŒtzlichen Wert hat, wie z. B. diesen Parameter, ist es hilfreich, die Standardwerte zu kennen und die benötigten Werte zurĂŒckzugeben, wie ich es im vorherigen Code mit *.egg dist build .
norecursedirs ist eine Art Konsequenz fĂŒr norecursedirs wir uns das spĂ€ter an.


Testverzeichnisbaumspezifikation


WĂ€hrend norecursedirs sagt, wo sie suchen sollen, testpaths Testpfade Pytest, wo sie suchen sollen. testspaths ist eine Liste von Verzeichnissen relativ zum Stammverzeichnis zum Suchen von Tests. Es wird nur verwendet, wenn das Verzeichnis, die Datei oder die nodeid nicht als Argument angegeben ist.


Angenommen, fĂŒr ein Tasks Projekt legen wir tasks_proj anstelle von tests im Verzeichnis tasks_proj :


 \code\tasks_proj>tree/f . │ pytest.ini │ ├───src │ └───tasks │ api.py │ ... │ └───tests │ conftest.py │ pytest.ini │ ├───func │ test_add.py │ ... │ ├───unit │ test_task.py │ __init__.py │ ...

Dann könnte es sinnvoll sein, die Tests in testpaths :


 [pytest] testpaths = tests

Wenn Sie jetzt pytest aus dem Verzeichnis task_proj tasks_proj , sucht pytest nur in tasks_proj/tests . Das Problem hierbei ist, dass ich wĂ€hrend der Entwicklung und des Debuggens von Tests hĂ€ufig ĂŒber das Testverzeichnis iteriere, sodass ich ein Unterverzeichnis oder eine Datei problemlos testen kann, ohne den gesamten Pfad anzugeben. Daher hilft mir diese Option beim interaktiven Testen ein wenig.


Es eignet sich jedoch hervorragend fĂŒr Tests, die von einem Continuous Integration Server oder Tox ausgefĂŒhrt werden. In diesen FĂ€llen wissen Sie, dass das Stammverzeichnis repariert wird, und Sie können die Verzeichnisse relativ zu diesem festen Stammverzeichnis auflisten. Dies sind auch die FĂ€lle, in denen Sie die Testzeit wirklich verkĂŒrzen möchten. Daher ist es großartig, die Suche nach Tests loszuwerden.


Auf den ersten Blick mag es albern erscheinen, sowohl norecursedirs als auch norecursedirs gleichzeitig zu verwenden. Wie Sie bereits gesehen haben, helfen Testpfade beim interaktiven Testen aus verschiedenen Teilen des Dateisystems nur wenig. In diesen FĂ€llen können norecursedirs helfen. Wenn Sie norecursedirs haben, die keine Tests enthalten, können Sie außerdem norecursedirs , um diese zu vermeiden. Aber was bringt es eigentlich, zusĂ€tzliche Verzeichnisse in Tests einzufĂŒgen, die keine Tests haben?


Ändern der Testerkennungsregeln


pytest findet Tests, die basierend auf bestimmten Testerkennungsregeln ausgefĂŒhrt werden sollen. Standardregeln fĂŒr die Testerkennung:


‱ Beginnen Sie mit einem oder mehreren Verzeichnissen. Sie können die Namen von Dateien oder Verzeichnissen in der Befehlszeile angeben. Wenn Sie nichts angegeben haben, wird das aktuelle Verzeichnis verwendet.
‱ Durchsuchen Sie den Katalog und alle seine Unterverzeichnisse nach Testmodulen.
‱ Ein Testmodul ist eine Datei mit einem Ă€hnlichen Namen wie test_*.py oder *_test.py .
‱ Suchen Sie in den Testmodulen nach Funktionen, die mit dem Test beginnen .
‱ Suchen Sie nach Klassen, die mit Test beginnen. Suchen Sie nach Methoden in Klassen, die mit `test beginnen , init` , .


Dies sind Standarderkennungsregeln. Sie können sie jedoch Àndern.


python_classes


Die ĂŒbliche Regel fĂŒr das Finden von Tests fĂŒr Pytest und Klassen besteht darin, eine Klasse als potenzielle Testklasse zu betrachten, wenn sie mit Test* beginnt. Die Klasse kann auch nicht die Methode __init__() . Aber was ist, wenn wir unsere Testklassen als <something>Test oder <something>Suite möchten? Hier kommt python_classes ins python_classes :


 [pytest] python_classes = *Test Test* *Suite

Dies ermöglicht es uns, die Klassen wie folgt zu benennen:


 class DeleteSuite(): def test_delete_1(): ... def test_delete_2(): ... ....

python_files


Wie pytest_classes Àndert python_files die Standard- python_files , die darin besteht, Dateien zu finden, die mit test_* beginnen oder am Ende *_test haben.
Angenommen, Sie haben ein benutzerdefiniertes check_<something>.py in dem Sie alle Ihre Testdateien check_<something>.py . Scheint vernĂŒnftig. Anstatt alle Ihre Dateien pytest.ini , fĂŒgen Sie pytest.ini wie folgt eine Zeile pytest.ini :


 [pytest] python_files = test_* *_test check_*

Sehr einfach. Jetzt können Sie die Namenskonvention nach und nach ĂŒbertragen, wenn Sie möchten, oder sie einfach als check_* .


python_functions


python_functions wie die beiden vorherigen Einstellungen, jedoch fĂŒr Testfunktionen und Methodennamen. Der Standardwert ist test_* . Und um check_* hinzuzufĂŒgen - Sie haben es erraten - tun Sie check_* :


 [pytest] python_functions = test_* check_*

Die pytest Namenskonventionen scheinen nicht so restriktiv zu sein, oder? Wenn Ihnen die Standardbenennungskonvention nicht gefĂ€llt, Ă€ndern Sie sie einfach. Ich fordere Sie jedoch dringend auf, einen zwingenderen Grund fĂŒr solche Entscheidungen zu haben. Die Migration von Hunderten von Testdateien ist definitiv ein guter Grund.


XPASS-Verbot


Das Setzen von xfail_strict = true bedeutet, dass die mit @pytest.mark.xfail gekennzeichneten Tests nicht als @pytest.mark.xfail erkannt werden. Ich denke, diese Einstellung sollte immer sein. Weitere Informationen zum xfail Token xfail Sie unter „Markieren von Tests, die auf einen Fehler warten“ auf Seite 37.


Verhindern Sie Konflikte mit Dateinamen


Die NĂŒtzlichkeit, die Datei __init__.py in jedem Test-Unterverzeichnis des Projekts zu haben, hat mich lange verwirrt. Der Unterschied, ob man sie hat oder nicht, ist jedoch einfach. Wenn Sie in all Ihren Test-Unterverzeichnissen __init__.py Dateien haben, können Sie denselben Testdateinamen in mehreren Verzeichnissen haben. Und wenn nicht, dann wird dies nicht funktionieren.


Hier ist ein Beispiel. Verzeichnis a und b beide die Datei test_foo.py . Es spielt keine Rolle, was diese Dateien enthalten, aber fĂŒr dieses Beispiel sehen sie folgendermaßen aus:


ch6 / dups / a / test_foo.py
 def test_a(): pass


ch6 / dups / b / test_foo.py
 def test_b(): pass

Mit dieser Verzeichnisstruktur:


 dups ├── a │ └── test_foo.py └── b └── test_foo.py

Diese Dateien haben nicht einmal den gleichen Inhalt, aber die Tests sind beschĂ€digt. Sie können sie separat ausfĂŒhren, es gibt jedoch keine Möglichkeit, pytest ĂŒber das Verzeichnis pytest dups :


 $ cd /path/to/code/ch6/dups $ pytest a ============================= test session starts ============================= collected 1 item a\test_foo.py . ========================== 1 passed in 0.05 seconds =========================== $ pytest b ============================= test session starts ============================= collected 1 item b\test_foo.py . ========================== 1 passed in 0.05 seconds =========================== $ pytest ============================= test session starts ============================= collected 1 item / 1 errors =================================== ERRORS ==================================== _______________________ ERROR collecting b/test_foo.py ________________________ import file mismatch: imported module 'test_foo' has this __file__ attribute: /path/to/code/ch6/dups/a/test_foo.py which is not the same as the test file we want to collect: /path/to/code/ch6/dups/b/test_foo.py HINT: remove __pycache__ / .pyc files and/or use a unique basename for your test file modules !!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!! =========================== 1 error in 0.34 seconds ===========================

Nichts ist klar!
Diese Fehlermeldung zeigt nicht an, was schief gelaufen ist.


Um diesen Test zu beheben, fĂŒgen Sie einfach die leere Datei __init__.py zu den Unterverzeichnissen hinzu. Hier ist ein Beispiel fĂŒr das Verzeichnis dups_fixed mit denselben doppelten Dateinamen, jedoch mit __init__.py Dateien __init__.py :


 dups_fixed/ ├── a │ ├── __init__.py │ └── test_foo.py └── b ├── __init__.py └── test_foo.py

Versuchen wir es jetzt noch einmal von der obersten Ebene in dups_fixed :


 $ cd /path/to/code/ch6/ch6/dups_fixed/ $ pytest ============================= test session starts ============================= collected 2 items a\test_foo.py . b\test_foo.py . ========================== 2 passed in 0.15 seconds ===========================

Also wird es besser sein.


NatĂŒrlich können Sie sich selbst davon ĂŒberzeugen, dass Sie niemals doppelte Dateinamen haben werden, also spielt das keine Rolle. Alles ist normal. Aber Projekte wachsen und Testkataloge wachsen, und Sie möchten auf jeden Fall warten, bis Ihnen dies passiert, bevor Sie sich darum kĂŒmmern? Ich sage, legen Sie diese Dateien einfach dort ab. Machen Sie es sich zur Gewohnheit und machen Sie sich keine Sorgen mehr.


Übungen


In Kapitel 5, Plugins, auf Seite 95 haben Sie ein Plugin namens pytest-nice erstellt, das eine Befehlszeilenoption --nice enthÀlt. Erweitern wir das um eine pytest.ini-Option namens nice.


In Kapitel 5, „Plugins“ auf Seite 95, haben Sie ein Plugin namens pytest-nice , das die --nice pytest-nice enthĂ€lt. Erweitern wir dies um die Option pytest.ini Namen nice .


  1. FĂŒgen Sie der Hook-Funktion pytest_addoption pytest_nice.py die folgende Zeile pytest_addoption : parser.addini('nice', type='bool', help='Turn failures into opportunities.')
  2. Stellen im Plugin, die getoption() mĂŒssen auch getini('nice') aufrufen. Nehmen Sie diese Änderungen vor.
  3. ÜberprĂŒfen Sie dies manuell, indem Sie der Datei pytest.ini nice pytest.ini .
  4. Plugin-Tests nicht vergessen. FĂŒgen Sie einen Test hinzu, um zu ĂŒberprĂŒfen, ob der nice Parameter aus pytest.ini ordnungsgemĂ€ĂŸ funktioniert.
  5. FĂŒgen Sie dem Plugin-Verzeichnis Tests hinzu. Sie mĂŒssen einige zusĂ€tzliche Pytester-Funktionen finden .

Was weiter


WÀhrend pytest an sich extrem leistungsfÀhig ist - insbesondere mit Plugins - lÀsst es sich auch gut in andere Softwareentwicklungs- und Softwaretest-Tools integrieren. Im nÀchsten Kapitel werden wir die Verwendung von Pytest in Verbindung mit anderen leistungsstarken Testwerkzeugen untersuchen.


ZurĂŒck Weiter

Source: https://habr.com/ru/post/de448796/

More articles:


All Articles