Provided by: python3-pytest_6.2.5-1ubuntu2_all 
NAME
pytest - pytest usage
CALLING PYTEST-3 THROUGH PYTHON -M PYTEST-3
You can invoke testing through the Python interpreter from the command line:
python -m pytest [...]
This is almost equivalent to invoking the command line script pytest [...] directly,
except that calling via python will also add the current directory to sys.path.
POSSIBLE EXIT CODES
Running pytest can result in six different exit codes:
Exit code 0
All tests were collected and passed successfully
Exit code 1
Tests were collected and run but some of the tests failed
Exit code 2
Test execution was interrupted by the user
Exit code 3
Internal error happened while executing tests
Exit code 4
pytest command line usage error
Exit code 5
No tests were collected
They are represented by the pytest.ExitCode enum. The exit codes being a part of the
public API can be imported and accessed directly using:
from pytest import ExitCode
NOTE:
If you would like to customize the exit code in some scenarios, specially when no tests
are collected, consider using the pytest-custom_exit_code plugin.
GETTING HELP ON VERSION, OPTION NAMES, ENVIRONMENT VARIABLES
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
The full command-line flags can be found in the reference.
STOPPING AFTER THE FIRST (OR N) FAILURES
To stop the testing process after the first (N) failures:
pytest -x # stop after first failure
pytest --maxfail=2 # stop after two failures
SPECIFYING TESTS / SELECTING TESTS
Pytest supports several ways to run and select tests from the command-line.
Run tests in a module
pytest test_mod.py
Run tests in a directory
pytest testing/
Run tests by keyword expressions
pytest -k "MyClass and not method"
This will run tests which contain names that match the given string expression
(case-insensitive), which can include Python operators that use filenames, class names and
function names as variables. The example above will run TestMyClass.test_something but
not TestMyClass.test_method_simple.
Run tests by node ids
Each collected test is assigned a unique nodeid which consist of the module filename
followed by specifiers like class names, function names and parameters from
parametrization, separated by :: characters.
To run a specific test within a module:
pytest test_mod.py::test_func
Another example specifying a test method in the command line:
pytest test_mod.py::TestClass::test_method
Run tests by marker expressions
pytest -m slow
Will run all tests which are decorated with the @pytest.mark.slow decorator.
For more information see marks.
Run tests from packages
pytest --pyargs pkg.testing
This will import pkg.testing and use its filesystem location to find and run tests from.
MODIFYING PYTHON TRACEBACK PRINTING
Examples for modifying traceback printing:
pytest --showlocals # show local variables in tracebacks
pytest -l # show local variables (shortcut)
pytest --tb=auto # (default) 'long' tracebacks for the first and last
# entry, but 'short' 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
The --full-trace causes very long traces to be printed on error (longer than --tb=long).
It also ensures that a stack trace is printed on KeyboardInterrupt (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 hanging. By default no output will be shown (because KeyboardInterrupt
is caught by pytest). By using this option you make sure a trace is shown.
DETAILED SUMMARY REPORT
The -r 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.
It defaults to fE to list failures and errors.
Example:
# 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
$ 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 ===
The -r options accepts a number of characters after it, with a used above meaning "all
except passes".
Here is the full list of available characters that can be used:
• f - failed
• E - error
• s - skipped
• x - xfailed
• X - xpassed
• p - passed
• P - passed with output
Special characters for (de)selection of groups:
• a - all except pP
• A - all
• N - none, this can be used to display nothing (since fE is the default)
More than one character can be used, so for example to only see failed and skipped tests,
you can execute:
$ 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 ===
Using p lists the passing tests, whilst P adds an extra section "PASSES" with those tests
that passed but had captured output:
$ 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 ===
DROPPING TO PDB (PYTHON DEBUGGER) ON FAILURES
Python comes with a builtin Python debugger called PDB. pytest allows one to drop into
the PDB prompt via a command line option:
pytest --pdb
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:
pytest -x --pdb # drop to PDB on first failure, then end test session
pytest --pdb --maxfail=3 # drop to PDB for first three failures
Note that on any failure the exception information is stored on sys.last_value,
sys.last_type and sys.last_traceback. 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:
>>> import sys
>>> sys.last_traceback.tb_lineno
42
>>> sys.last_value
AssertionError('assert result == "ok"',)
DROPPING TO PDB (PYTHON DEBUGGER) AT THE START OF A TEST
pytest allows one to drop into the PDB prompt immediately at the start of each test via a
command line option:
pytest --trace
This will invoke the Python debugger at the start of every test.
SETTING BREAKPOINTS
To set a breakpoint in your code use the native Python import pdb;pdb.set_trace() call in
your code and pytest automatically disables its output capture for that test:
• Output capture in other tests is not affected.
• Any prior test output that has already been captured and will be processed as such.
• Output capture gets resumed when ending the debugger session (via the continue command).
USING THE BUILTIN BREAKPOINT FUNCTION
Python 3.7 introduces a builtin breakpoint() function. Pytest supports the use of
breakpoint() with the following behaviours:
• When breakpoint() is called and PYTHONBREAKPOINT is set to the default value, pytest
will use the custom internal PDB trace UI instead of the system default Pdb.
• When tests are complete, the system will default back to the system Pdb trace UI.
• With --pdb passed to pytest, the custom internal Pdb trace UI is used with both
breakpoint() and failed tests/unhandled exceptions.
• --pdbcls can be used to specify a custom debugger class.
PROFILING TEST EXECUTION DURATION
Changed in version 6.0.
To get a list of the slowest 10 test durations over 1.0s long:
pytest --durations=10 --durations-min=1.0
By default, pytest will not show test durations that are too small (<0.005s) unless -vv is
passed on the command-line.
FAULT HANDLER
New in version 5.0.
The faulthandler standard module can be used to dump Python tracebacks on a segfault or
after a timeout.
The module is automatically enabled for pytest runs, unless the -p no:faulthandler is
given on the command-line.
Also the faulthandler_timeout=X configuration option can be used to dump the traceback of
all threads if a test takes longer than X seconds to finish (not available on Windows).
NOTE:
This functionality has been integrated from the external pytest-faulthandler plugin,
with two small differences:
• To disable it, use -p no:faulthandler instead of --no-faulthandler: the former can be
used with any plugin, so it saves one option.
• The --faulthandler-timeout command-line option has become the faulthandler_timeout
configuration option. It can still be configured from the command-line using -o
faulthandler_timeout=X.
WARNING ABOUT UNRAISABLE EXCEPTIONS AND UNHANDLED THREAD EXCEPTIONS
New in version 6.2.
NOTE:
These features only work on Python>=3.8.
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 __del__
implementation.
Unhandled thread exceptions are exceptions raised in a Thread but not handled, causing the
thread to terminate uncleanly.
Both types of exceptions are normally considered bugs, but may go unnoticed because they
don't cause the program itself to crash. Pytest detects these conditions and issues a
warning that is visible in the test run summary.
The plugins are automatically enabled for pytest runs, unless the -p
no:unraisableexception (for unraisable exceptions) and -p no:threadexception (for thread
exceptions) options are given on the command-line.
The warnings may be silenced selectivly using the pytest.mark.filterwarnings ref mark. The
warning categories are pytest.PytestUnraisableExceptionWarning and
pytest.PytestUnhandledThreadExceptionWarning.
CREATING JUNITXML FORMAT FILES
To create result files which can be read by Jenkins or other Continuous integration
servers, use this invocation:
pytest --junitxml=path
to create an XML file at path.
To set the name of the root test suite xml item, you can configure the junit_suite_name
option in your config file:
[pytest]
junit_suite_name = my_suite
New in version 4.0.
JUnit XML specification seems to indicate that "time" attribute should report total test
execution times, including setup and teardown (1, 2). It is the default pytest behavior.
To report just call durations instead, configure the junit_duration_report option like
this:
[pytest]
junit_duration_report = call
record_property
If you want to log additional information for a test, you can use the record_property
fixture:
def test_function(record_property):
record_property("example_key", 1)
assert True
This will add an extra property example_key="1" to the generated testcase tag:
<testcase classname="test_function" file="test_function.py" line="0" name="test_function" time="0.0009">
<properties>
<property name="example_key" value="1" />
</properties>
</testcase>
Alternatively, you can integrate this functionality with custom markers:
# 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))
And in your tests:
# content of test_function.py
import pytest
@pytest.mark.test_id(1501)
def test_function():
assert True
Will result in:
<testcase classname="test_function" file="test_function.py" line="0" name="test_function" time="0.0009">
<properties>
<property name="test_id" value="1501" />
</properties>
</testcase>
WARNING:
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.
record_xml_attribute
To add an additional xml attribute to a testcase element, you can use record_xml_attribute
fixture. This can also be used to override existing values:
def test_function(record_xml_attribute):
record_xml_attribute("assertions", "REQ-1234")
record_xml_attribute("classname", "custom_classname")
print("hello world")
assert True
Unlike record_property, this will not add a new child element. Instead, this will add an
attribute assertions="REQ-1234" inside the generated testcase tag and override the default
classname with "classname=custom_classname":
<testcase classname="custom_classname" file="test_function.py" line="0" name="test_function" time="0.003" assertions="REQ-1234">
<system-out>
hello world
</system-out>
</testcase>
WARNING:
record_xml_attribute 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.
Using this over record_xml_property 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.
Below is the Scheme used by Jenkins to validate the XML report:
<xs:element name="testcase">
<xs:complexType>
<xs:sequence>
<xs:element ref="skipped" minOccurs="0" maxOccurs="1"/>
<xs:element ref="error" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="failure" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="system-out" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="system-err" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="assertions" type="xs:string" use="optional"/>
<xs:attribute name="time" type="xs:string" use="optional"/>
<xs:attribute name="classname" type="xs:string" use="optional"/>
<xs:attribute name="status" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
WARNING:
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.
record_testsuite_property
New in version 4.5.
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 record_testsuite_property
session-scoped fixture:
The record_testsuite_property session-scoped fixture can be used to add properties
relevant to all tests.
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
The fixture is a callable which receives name and value of a <property> tag added at the
test-suite level of the generated xml:
<testsuite errors="0" failures="0" name="pytest" skipped="0" tests="1" time="0.006">
<properties>
<property name="ARCH" value="PPC"/>
<property name="STORAGE_TYPE" value="CEPH"/>
</properties>
<testcase classname="test_me.TestMe" file="test_me.py" line="16" name="test_foo" time="0.000243663787842"/>
</testsuite>
name must be a string, value will be converted to a string and properly xml-escaped.
The generated XML is compatible with the latest xunit standard, contrary to
record_property and record_xml_attribute.
CREATING RESULTLOG FORMAT FILES
To create plain-text machine-readable result files you can issue:
pytest --resultlog=path
and look at the content at the path location. Such files are used e.g. by the PyPy-test
web page to show test results over several revisions.
WARNING:
This option is rarely used and is scheduled for removal in pytest 6.0.
If you use this option, consider using the new pytest-reportlog plugin instead.
See the deprecation docs for more information.
SENDING TEST REPORT TO ONLINE PASTEBIN SERVICE
Creating a URL for each test failure:
pytest --pastebin=failed
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 -x if you only want to send one
particular failure.
Creating a URL for a whole test session log:
pytest --pastebin=all
Currently only pasting to the http://bpaste.net service is implemented.
Changed in version 5.2.
If creating the URL fails for any reason, a warning is generated instead of failing the
entire test suite.
EARLY LOADING PLUGINS
You can early-load plugins (internal and external) explicitly in the command-line with the
-p option:
pytest -p mypluginmodule
The option receives a name parameter, which can be:
• A full module dotted name, for example myproject.plugins. This dotted name must be
importable.
• The entry-point name of a plugin. This is the name passed to setuptools when the plugin
is registered. For example to early-load the pytest-cov plugin you can use:
pytest -p pytest_cov
DISABLING PLUGINS
To disable loading specific plugins at invocation time, use the -p option together with
the prefix no:.
Example: to disable loading the plugin doctest, which is responsible for executing doctest
tests from text files, invoke pytest like this:
pytest -p no:doctest
CALLING PYTEST-3 FROM PYTHON CODE
You can invoke pytest from Python code directly:
pytest.main()
this acts as if you would call "pytest" from the command line. It will not raise
SystemExit but return the exitcode instead. You can pass in options and arguments:
pytest.main(["-x", "mytestdir"])
You can specify additional plugins to pytest.main:
# content of myinvoke.py
import pytest
class MyPlugin:
def pytest_sessionfinish(self):
print("*** test run reporting finishing")
pytest.main(["-qq"], plugins=[MyPlugin()])
Running it will show that MyPlugin was added and its hook was invoked:
$ 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
NOTE:
Calling pytest.main() will result in importing your tests and any modules that they
import. Due to the caching mechanism of python's import system, making subsequent calls
to pytest.main() from the same process will not reflect changes to those files between
the calls. For this reason, making multiple calls to pytest.main() from the same
process (in order to re-run tests, for example) is not recommended.
AUTHOR
holger krekel at merlinux eu
COPYRIGHT
2015–2020, holger krekel and pytest-dev team