.\" Man page generated from reStructuredText. . . .nr rst2man-indent-level 0 . .de1 rstReportMargin \\$1 \\n[an-margin] level \\n[rst2man-indent-level] level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] - \\n[rst2man-indent0] \\n[rst2man-indent1] \\n[rst2man-indent2] .. .de1 INDENT .\" .rstReportMargin pre: . RS \\$1 . nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin] . nr rst2man-indent-level +1 .\" .rstReportMargin post: .. .de UNINDENT . RE .\" indent \\n[an-margin] .\" old: \\n[rst2man-indent\\n[rst2man-indent-level]] .nr rst2man-indent-level -1 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]] .in \\n[rst2man-indent\\n[rst2man-indent-level]]u .. .TH "PYTEST-3" "1" "Mar 15, 2022" "6.2.5" "pytest" .SH NAME pytest \- pytest usage .SH CALLING PYTEST-3 THROUGH PYTHON -M PYTEST-3 .sp You can invoke testing through the Python interpreter from the command line: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C python \-m pytest [...] .ft P .fi .UNINDENT .UNINDENT .sp This is almost equivalent to invoking the command line script \fBpytest [...]\fP directly, except that calling via \fBpython\fP will also add the current directory to \fBsys.path\fP\&. .SH POSSIBLE EXIT CODES .sp Running \fBpytest\fP can result in six different exit codes: .INDENT 0.0 .TP .B Exit code 0 All tests were collected and passed successfully .TP .B Exit code 1 Tests were collected and run but some of the tests failed .TP .B Exit code 2 Test execution was interrupted by the user .TP .B Exit code 3 Internal error happened while executing tests .TP .B Exit code 4 pytest command line usage error .TP .B Exit code 5 No tests were collected .UNINDENT .sp They are represented by the \fBpytest.ExitCode\fP enum. The exit codes being a part of the public API can be imported and accessed directly using: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C from pytest import ExitCode .ft P .fi .UNINDENT .UNINDENT .sp \fBNOTE:\fP .INDENT 0.0 .INDENT 3.5 If you would like to customize the exit code in some scenarios, specially when no tests are collected, consider using the \fI\%pytest\-custom_exit_code\fP plugin. .UNINDENT .UNINDENT .SH GETTING HELP ON VERSION, OPTION NAMES, ENVIRONMENT VARIABLES .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-\-version # shows where pytest was imported from pytest \-\-fixtures # show available builtin function arguments pytest \-h | \-\-help # show help on command line and config file options .ft P .fi .UNINDENT .UNINDENT .sp The full command\-line flags can be found in the reference\&. .SH STOPPING AFTER THE FIRST (OR N) FAILURES .sp To stop the testing process after the first (N) failures: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-x # stop after first failure pytest \-\-maxfail=2 # stop after two failures .ft P .fi .UNINDENT .UNINDENT .SH SPECIFYING TESTS / SELECTING TESTS .sp Pytest supports several ways to run and select tests from the command\-line. .sp \fBRun tests in a module\fP .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest test_mod.py .ft P .fi .UNINDENT .UNINDENT .sp \fBRun tests in a directory\fP .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest testing/ .ft P .fi .UNINDENT .UNINDENT .sp \fBRun tests by keyword expressions\fP .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-k "MyClass and not method" .ft P .fi .UNINDENT .UNINDENT .sp This will run tests which contain names that match the given \fIstring expression\fP (case\-insensitive), which can include Python operators that use filenames, class names and function names as variables. The example above will run \fBTestMyClass.test_something\fP but not \fBTestMyClass.test_method_simple\fP\&. .sp \fBRun tests by node ids\fP .sp Each collected test is assigned a unique \fBnodeid\fP which consist of the module filename followed by specifiers like class names, function names and parameters from parametrization, separated by \fB::\fP characters. .sp To run a specific test within a module: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest test_mod.py::test_func .ft P .fi .UNINDENT .UNINDENT .sp Another example specifying a test method in the command line: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest test_mod.py::TestClass::test_method .ft P .fi .UNINDENT .UNINDENT .sp \fBRun tests by marker expressions\fP .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-m slow .ft P .fi .UNINDENT .UNINDENT .sp Will run all tests which are decorated with the \fB@pytest.mark.slow\fP decorator. .sp For more information see marks\&. .sp \fBRun tests from packages\fP .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-\-pyargs pkg.testing .ft P .fi .UNINDENT .UNINDENT .sp This will import \fBpkg.testing\fP and use its filesystem location to find and run tests from. .SH MODIFYING PYTHON TRACEBACK PRINTING .sp Examples for modifying traceback printing: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-\-showlocals # show local variables in tracebacks pytest \-l # show local variables (shortcut) pytest \-\-tb=auto # (default) \(aqlong\(aq tracebacks for the first and last # entry, but \(aqshort\(aq style for the other entries pytest \-\-tb=long # exhaustive, informative traceback formatting pytest \-\-tb=short # shorter traceback format pytest \-\-tb=line # only one line per failure pytest \-\-tb=native # Python standard library formatting pytest \-\-tb=no # no traceback at all .ft P .fi .UNINDENT .UNINDENT .sp The \fB\-\-full\-trace\fP causes very long traces to be printed on error (longer than \fB\-\-tb=long\fP). It also ensures that a stack trace is printed on \fBKeyboardInterrupt\fP (Ctrl+C). This is very useful if the tests are taking too long and you interrupt them with Ctrl+C to find out where the tests are \fIhanging\fP\&. By default no output will be shown (because KeyboardInterrupt is caught by pytest). By using this option you make sure a trace is shown. .SH DETAILED SUMMARY REPORT .sp The \fB\-r\fP flag can be used to display a "short test summary info" at the end of the test session, making it easy in large test suites to get a clear picture of all failures, skips, xfails, etc. .sp It defaults to \fBfE\fP to list failures and errors. .sp Example: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C # content of test_example.py import pytest @pytest.fixture def error_fixture(): assert 0 def test_ok(): print("ok") def test_fail(): assert 0 def test_error(error_fixture): pass def test_skip(): pytest.skip("skipping this test") def test_xfail(): pytest.xfail("xfailing this test") @pytest.mark.xfail(reason="always xfail") def test_xpass(): pass .ft P .fi .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C $ pytest \-ra =========================== test session starts ============================ platform linux \-\- Python 3.x.y, pytest\-6.x.y, py\-1.x.y, pluggy\-1.x.y cachedir: $PYTHON_PREFIX/.pytest_cache rootdir: $REGENDOC_TMPDIR collected 6 items test_example.py .FEsxX [100%] ================================== ERRORS ================================== _______________________ ERROR at setup of test_error _______________________ @pytest.fixture def error_fixture(): > assert 0 E assert 0 test_example.py:6: AssertionError ================================= FAILURES ================================= ________________________________ test_fail _________________________________ def test_fail(): > assert 0 E assert 0 test_example.py:14: AssertionError ========================= short test summary info ========================== SKIPPED [1] test_example.py:22: skipping this test XFAIL test_example.py::test_xfail reason: xfailing this test XPASS test_example.py::test_xpass always xfail ERROR test_example.py::test_error \- assert 0 FAILED test_example.py::test_fail \- assert 0 == 1 failed, 1 passed, 1 skipped, 1 xfailed, 1 xpassed, 1 error in 0.12s === .ft P .fi .UNINDENT .UNINDENT .sp The \fB\-r\fP options accepts a number of characters after it, with \fBa\fP used above meaning "all except passes". .sp Here is the full list of available characters that can be used: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fBf\fP \- failed .IP \(bu 2 \fBE\fP \- error .IP \(bu 2 \fBs\fP \- skipped .IP \(bu 2 \fBx\fP \- xfailed .IP \(bu 2 \fBX\fP \- xpassed .IP \(bu 2 \fBp\fP \- passed .IP \(bu 2 \fBP\fP \- passed with output .UNINDENT .UNINDENT .UNINDENT .sp Special characters for (de)selection of groups: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fBa\fP \- all except \fBpP\fP .IP \(bu 2 \fBA\fP \- all .IP \(bu 2 \fBN\fP \- none, this can be used to display nothing (since \fBfE\fP is the default) .UNINDENT .UNINDENT .UNINDENT .sp More than one character can be used, so for example to only see failed and skipped tests, you can execute: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C $ pytest \-rfs =========================== test session starts ============================ platform linux \-\- Python 3.x.y, pytest\-6.x.y, py\-1.x.y, pluggy\-1.x.y cachedir: $PYTHON_PREFIX/.pytest_cache rootdir: $REGENDOC_TMPDIR collected 6 items test_example.py .FEsxX [100%] ================================== ERRORS ================================== _______________________ ERROR at setup of test_error _______________________ @pytest.fixture def error_fixture(): > assert 0 E assert 0 test_example.py:6: AssertionError ================================= FAILURES ================================= ________________________________ test_fail _________________________________ def test_fail(): > assert 0 E assert 0 test_example.py:14: AssertionError ========================= short test summary info ========================== FAILED test_example.py::test_fail \- assert 0 SKIPPED [1] test_example.py:22: skipping this test == 1 failed, 1 passed, 1 skipped, 1 xfailed, 1 xpassed, 1 error in 0.12s === .ft P .fi .UNINDENT .UNINDENT .sp Using \fBp\fP lists the passing tests, whilst \fBP\fP adds an extra section "PASSES" with those tests that passed but had captured output: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C $ pytest \-rpP =========================== test session starts ============================ platform linux \-\- Python 3.x.y, pytest\-6.x.y, py\-1.x.y, pluggy\-1.x.y cachedir: $PYTHON_PREFIX/.pytest_cache rootdir: $REGENDOC_TMPDIR collected 6 items test_example.py .FEsxX [100%] ================================== ERRORS ================================== _______________________ ERROR at setup of test_error _______________________ @pytest.fixture def error_fixture(): > assert 0 E assert 0 test_example.py:6: AssertionError ================================= FAILURES ================================= ________________________________ test_fail _________________________________ def test_fail(): > assert 0 E assert 0 test_example.py:14: AssertionError ================================== PASSES ================================== _________________________________ test_ok __________________________________ \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- Captured stdout call \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- ok ========================= short test summary info ========================== PASSED test_example.py::test_ok == 1 failed, 1 passed, 1 skipped, 1 xfailed, 1 xpassed, 1 error in 0.12s === .ft P .fi .UNINDENT .UNINDENT .SH DROPPING TO PDB (PYTHON DEBUGGER) ON FAILURES .sp Python comes with a builtin Python debugger called \fI\%PDB\fP\&. \fBpytest\fP allows one to drop into the \fI\%PDB\fP prompt via a command line option: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-\-pdb .ft P .fi .UNINDENT .UNINDENT .sp This will invoke the Python debugger on every failure (or KeyboardInterrupt). Often you might only want to do this for the first failing test to understand a certain failure situation: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-x \-\-pdb # drop to PDB on first failure, then end test session pytest \-\-pdb \-\-maxfail=3 # drop to PDB for first three failures .ft P .fi .UNINDENT .UNINDENT .sp Note that on any failure the exception information is stored on \fBsys.last_value\fP, \fBsys.last_type\fP and \fBsys.last_traceback\fP\&. In interactive use, this allows one to drop into postmortem debugging with any debug tool. One can also manually access the exception information, for example: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C >>> import sys >>> sys.last_traceback.tb_lineno 42 >>> sys.last_value AssertionError(\(aqassert result == "ok"\(aq,) .ft P .fi .UNINDENT .UNINDENT .SH DROPPING TO PDB (PYTHON DEBUGGER) AT THE START OF A TEST .sp \fBpytest\fP allows one to drop into the \fI\%PDB\fP prompt immediately at the start of each test via a command line option: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-\-trace .ft P .fi .UNINDENT .UNINDENT .sp This will invoke the Python debugger at the start of every test. .SH SETTING BREAKPOINTS .sp To set a breakpoint in your code use the native Python \fBimport pdb;pdb.set_trace()\fP call in your code and pytest automatically disables its output capture for that test: .INDENT 0.0 .IP \(bu 2 Output capture in other tests is not affected. .IP \(bu 2 Any prior test output that has already been captured and will be processed as such. .IP \(bu 2 Output capture gets resumed when ending the debugger session (via the \fBcontinue\fP command). .UNINDENT .SH USING THE BUILTIN BREAKPOINT FUNCTION .sp Python 3.7 introduces a builtin \fBbreakpoint()\fP function. Pytest supports the use of \fBbreakpoint()\fP with the following behaviours: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 When \fBbreakpoint()\fP is called and \fBPYTHONBREAKPOINT\fP is set to the default value, pytest will use the custom internal PDB trace UI instead of the system default \fBPdb\fP\&. .IP \(bu 2 When tests are complete, the system will default back to the system \fBPdb\fP trace UI. .IP \(bu 2 With \fB\-\-pdb\fP passed to pytest, the custom internal Pdb trace UI is used with both \fBbreakpoint()\fP and failed tests/unhandled exceptions. .IP \(bu 2 \fB\-\-pdbcls\fP can be used to specify a custom debugger class. .UNINDENT .UNINDENT .UNINDENT .SH PROFILING TEST EXECUTION DURATION .sp Changed in version 6.0. .sp To get a list of the slowest 10 test durations over 1.0s long: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-\-durations=10 \-\-durations\-min=1.0 .ft P .fi .UNINDENT .UNINDENT .sp By default, pytest will not show test durations that are too small (<0.005s) unless \fB\-vv\fP is passed on the command\-line. .SH FAULT HANDLER .sp New in version 5.0. .sp The \fI\%faulthandler\fP standard module can be used to dump Python tracebacks on a segfault or after a timeout. .sp The module is automatically enabled for pytest runs, unless the \fB\-p no:faulthandler\fP is given on the command\-line. .sp Also the \fBfaulthandler_timeout=X\fP configuration option can be used to dump the traceback of all threads if a test takes longer than \fBX\fP seconds to finish (not available on Windows). .sp \fBNOTE:\fP .INDENT 0.0 .INDENT 3.5 This functionality has been integrated from the external \fI\%pytest\-faulthandler\fP plugin, with two small differences: .INDENT 0.0 .IP \(bu 2 To disable it, use \fB\-p no:faulthandler\fP instead of \fB\-\-no\-faulthandler\fP: the former can be used with any plugin, so it saves one option. .IP \(bu 2 The \fB\-\-faulthandler\-timeout\fP command\-line option has become the \fBfaulthandler_timeout\fP configuration option. It can still be configured from the command\-line using \fB\-o faulthandler_timeout=X\fP\&. .UNINDENT .UNINDENT .UNINDENT .SH WARNING ABOUT UNRAISABLE EXCEPTIONS AND UNHANDLED THREAD EXCEPTIONS .sp New in version 6.2. .sp \fBNOTE:\fP .INDENT 0.0 .INDENT 3.5 These features only work on Python>=3.8. .UNINDENT .UNINDENT .sp Unhandled exceptions are exceptions that are raised in a situation in which they cannot propagate to a caller. The most common case is an exception raised in a \fI\%__del__\fP implementation. .sp Unhandled thread exceptions are exceptions raised in a \fI\%Thread\fP but not handled, causing the thread to terminate uncleanly. .sp Both types of exceptions are normally considered bugs, but may go unnoticed because they don\(aqt cause the program itself to crash. Pytest detects these conditions and issues a warning that is visible in the test run summary. .sp The plugins are automatically enabled for pytest runs, unless the \fB\-p no:unraisableexception\fP (for unraisable exceptions) and \fB\-p no:threadexception\fP (for thread exceptions) options are given on the command\-line. .sp The warnings may be silenced selectivly using the pytest.mark.filterwarnings ref mark. The warning categories are \fBpytest.PytestUnraisableExceptionWarning\fP and \fBpytest.PytestUnhandledThreadExceptionWarning\fP\&. .SH CREATING JUNITXML FORMAT FILES .sp To create result files which can be read by \fI\%Jenkins\fP or other Continuous integration servers, use this invocation: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-\-junitxml=path .ft P .fi .UNINDENT .UNINDENT .sp to create an XML file at \fBpath\fP\&. .sp To set the name of the root test suite xml item, you can configure the \fBjunit_suite_name\fP option in your config file: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C [pytest] junit_suite_name = my_suite .ft P .fi .UNINDENT .UNINDENT .sp New in version 4.0. .sp JUnit XML specification seems to indicate that \fB"time"\fP attribute should report total test execution times, including setup and teardown (\fI\%1\fP, \fI\%2\fP). It is the default pytest behavior. To report just call durations instead, configure the \fBjunit_duration_report\fP option like this: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C [pytest] junit_duration_report = call .ft P .fi .UNINDENT .UNINDENT .SS record_property .sp If you want to log additional information for a test, you can use the \fBrecord_property\fP fixture: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C def test_function(record_property): record_property("example_key", 1) assert True .ft P .fi .UNINDENT .UNINDENT .sp This will add an extra property \fBexample_key="1"\fP to the generated \fBtestcase\fP tag: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C .ft P .fi .UNINDENT .UNINDENT .sp Alternatively, you can integrate this functionality with custom markers: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C # content of conftest.py def pytest_collection_modifyitems(session, config, items): for item in items: for marker in item.iter_markers(name="test_id"): test_id = marker.args[0] item.user_properties.append(("test_id", test_id)) .ft P .fi .UNINDENT .UNINDENT .sp And in your tests: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C # content of test_function.py import pytest @pytest.mark.test_id(1501) def test_function(): assert True .ft P .fi .UNINDENT .UNINDENT .sp Will result in: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C .ft P .fi .UNINDENT .UNINDENT .sp \fBWARNING:\fP .INDENT 0.0 .INDENT 3.5 Please note that using this feature will break schema verifications for the latest JUnitXML schema. This might be a problem when used with some CI servers. .UNINDENT .UNINDENT .SS record_xml_attribute .sp To add an additional xml attribute to a testcase element, you can use \fBrecord_xml_attribute\fP fixture. This can also be used to override existing values: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C def test_function(record_xml_attribute): record_xml_attribute("assertions", "REQ\-1234") record_xml_attribute("classname", "custom_classname") print("hello world") assert True .ft P .fi .UNINDENT .UNINDENT .sp Unlike \fBrecord_property\fP, this will not add a new child element. Instead, this will add an attribute \fBassertions="REQ\-1234"\fP inside the generated \fBtestcase\fP tag and override the default \fBclassname\fP with \fB"classname=custom_classname"\fP: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C hello world .ft P .fi .UNINDENT .UNINDENT .sp \fBWARNING:\fP .INDENT 0.0 .INDENT 3.5 \fBrecord_xml_attribute\fP is an experimental feature, and its interface might be replaced by something more powerful and general in future versions. The functionality per\-se will be kept, however. .sp Using this over \fBrecord_xml_property\fP can help when using ci tools to parse the xml report. However, some parsers are quite strict about the elements and attributes that are allowed. Many tools use an xsd schema (like the example below) to validate incoming xml. Make sure you are using attribute names that are allowed by your parser. .sp Below is the Scheme used by Jenkins to validate the XML report: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C .ft P .fi .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp \fBWARNING:\fP .INDENT 0.0 .INDENT 3.5 Please note that using this feature will break schema verifications for the latest JUnitXML schema. This might be a problem when used with some CI servers. .UNINDENT .UNINDENT .SS record_testsuite_property .sp New in version 4.5. .sp If you want to add a properties node at the test\-suite level, which may contains properties that are relevant to all tests, you can use the \fBrecord_testsuite_property\fP session\-scoped fixture: .sp The \fBrecord_testsuite_property\fP session\-scoped fixture can be used to add properties relevant to all tests. .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C import pytest @pytest.fixture(scope="session", autouse=True) def log_global_env_facts(record_testsuite_property): record_testsuite_property("ARCH", "PPC") record_testsuite_property("STORAGE_TYPE", "CEPH") class TestMe: def test_foo(self): assert True .ft P .fi .UNINDENT .UNINDENT .sp The fixture is a callable which receives \fBname\fP and \fBvalue\fP of a \fB\fP tag added at the test\-suite level of the generated xml: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C .ft P .fi .UNINDENT .UNINDENT .sp \fBname\fP must be a string, \fBvalue\fP will be converted to a string and properly xml\-escaped. .sp The generated XML is compatible with the latest \fBxunit\fP standard, contrary to \fI\%record_property\fP and \fI\%record_xml_attribute\fP\&. .SH CREATING RESULTLOG FORMAT FILES .sp To create plain\-text machine\-readable result files you can issue: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-\-resultlog=path .ft P .fi .UNINDENT .UNINDENT .sp and look at the content at the \fBpath\fP location. Such files are used e.g. by the \fI\%PyPy\-test\fP web page to show test results over several revisions. .sp \fBWARNING:\fP .INDENT 0.0 .INDENT 3.5 This option is rarely used and is scheduled for removal in pytest 6.0. .sp If you use this option, consider using the new \fI\%pytest\-reportlog\fP plugin instead. .sp See \fI\%the deprecation docs\fP for more information. .UNINDENT .UNINDENT .SH SENDING TEST REPORT TO ONLINE PASTEBIN SERVICE .sp \fBCreating a URL for each test failure\fP: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-\-pastebin=failed .ft P .fi .UNINDENT .UNINDENT .sp This will submit test run information to a remote Paste service and provide a URL for each failure. You may select tests as usual or add for example \fB\-x\fP if you only want to send one particular failure. .sp \fBCreating a URL for a whole test session log\fP: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-\-pastebin=all .ft P .fi .UNINDENT .UNINDENT .sp Currently only pasting to the \fI\%http://bpaste.net\fP service is implemented. .sp Changed in version 5.2. .sp If creating the URL fails for any reason, a warning is generated instead of failing the entire test suite. .SH EARLY LOADING PLUGINS .sp You can early\-load plugins (internal and external) explicitly in the command\-line with the \fB\-p\fP option: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-p mypluginmodule .ft P .fi .UNINDENT .UNINDENT .sp The option receives a \fBname\fP parameter, which can be: .INDENT 0.0 .IP \(bu 2 A full module dotted name, for example \fBmyproject.plugins\fP\&. This dotted name must be importable. .IP \(bu 2 The entry\-point name of a plugin. This is the name passed to \fBsetuptools\fP when the plugin is registered. For example to early\-load the \fI\%pytest\-cov\fP plugin you can use: .INDENT 2.0 .INDENT 3.5 .sp .nf .ft C pytest \-p pytest_cov .ft P .fi .UNINDENT .UNINDENT .UNINDENT .SH DISABLING PLUGINS .sp To disable loading specific plugins at invocation time, use the \fB\-p\fP option together with the prefix \fBno:\fP\&. .sp Example: to disable loading the plugin \fBdoctest\fP, which is responsible for executing doctest tests from text files, invoke pytest like this: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest \-p no:doctest .ft P .fi .UNINDENT .UNINDENT .SH CALLING PYTEST-3 FROM PYTHON CODE .sp You can invoke \fBpytest\fP from Python code directly: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest.main() .ft P .fi .UNINDENT .UNINDENT .sp this acts as if you would call "pytest" from the command line. It will not raise \fBSystemExit\fP but return the exitcode instead. You can pass in options and arguments: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C pytest.main(["\-x", "mytestdir"]) .ft P .fi .UNINDENT .UNINDENT .sp You can specify additional plugins to \fBpytest.main\fP: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C # content of myinvoke.py import pytest class MyPlugin: def pytest_sessionfinish(self): print("*** test run reporting finishing") pytest.main(["\-qq"], plugins=[MyPlugin()]) .ft P .fi .UNINDENT .UNINDENT .sp Running it will show that \fBMyPlugin\fP was added and its hook was invoked: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C $ python myinvoke.py \&.FEsxX. [100%]*** test run reporting finishing ================================== ERRORS ================================== _______________________ ERROR at setup of test_error _______________________ @pytest.fixture def error_fixture(): > assert 0 E assert 0 test_example.py:6: AssertionError ================================= FAILURES ================================= ________________________________ test_fail _________________________________ def test_fail(): > assert 0 E assert 0 test_example.py:14: AssertionError ========================= short test summary info ========================== FAILED test_example.py::test_fail \- assert 0 ERROR test_example.py::test_error \- assert 0 .ft P .fi .UNINDENT .UNINDENT .sp \fBNOTE:\fP .INDENT 0.0 .INDENT 3.5 Calling \fBpytest.main()\fP will result in importing your tests and any modules that they import. Due to the caching mechanism of python\(aqs import system, making subsequent calls to \fBpytest.main()\fP from the same process will not reflect changes to those files between the calls. For this reason, making multiple calls to \fBpytest.main()\fP from the same process (in order to re\-run tests, for example) is not recommended. .UNINDENT .UNINDENT .SH AUTHOR holger krekel at merlinux eu .SH COPYRIGHT 2015–2020, holger krekel and pytest-dev team .\" Generated by docutils manpage writer. .