With the pytest 3.0 release, we introduced a clear communication scheme for when we will actually remove the old busted joint and politely ask you to use the new hotness instead, while giving you enough time to adjust your tests or raise concerns if there are valid reasons to keep deprecated functionality around.

We will only start the removal of deprecated functionality in major releases (e.g. if we deprecate something in 3.0, we will start to remove it in 4.0), and keep it around for at least two minor releases (e.g. if we deprecate something in 3.9 and 4.0 is the next release, we start to remove it in 5.0, not in 4.0).

For information on the ``pytest.mark`` mechanism, see :ref:`mark`.

.. code-block:: pytest

.. versionadded:: 2.0/2.3.4

which implements a substring match on the test names instead of the

select tests based on their names:

.. versionchanged:: 5.4

You can use ``and``, ``or``, ``not`` and parentheses.

attributes set on the test function, markers applied to it or its parents and any :attr:`extra keywords <_pytest.nodes.Node.extra_keyword_matches>`

explicitly added to it or its parents.

.. code-block:: pytest

If you have a test suite where test function names indicate a certain

type of test, you can implement a hook that automatically defines

at this test module:

.. code-block:: python

pytest will build a string that is the test ID for each set of values in a

to run, and they will also identify the specific case when one is failing.

Numbers, strings, booleans and None will have their usual string representation

used in the test ID. For other objects, pytest will make a string based on

You can easily ignore certain test directories and modules during collection

``--ignore`` options. Example:

.. code-block:: text

Deselect tests during test collection

For example, say ``tests/foobar/test_foobar_01.py`` contains ``test_a`` and ``test_b``.

You can run all of the tests within ``tests/`` *except* for ``tests/foobar/test_foobar_01.py::test_a``

``pytest`` allows multiple ``--deselect`` options.

.. _duplicate-paths:

Just collect tests once.

Example:

.. code-block:: pytest

Interpreting cmdline arguments as Python packages

interpreting arguments as python package names, deriving

their file system path and then running the test. For

example if you have unittest2 installed you can type:

Note that as usual for other command-line applications, in case of conflicting options the last one wins, so the example

.. _request example:

The ``__tracebackhide__`` setting influences ``pytest`` showing

of tracebacks: the ``checkconfig`` function will not be shown

Let's run our little function:

.. code-block:: pytest

Sometimes a test session might get stuck and there might be no easy way to figure out

output. This is particularly a problem if the problem happens only sporadically, the famous "flaky" kind of tests.

``pytest`` sets the :envvar:`PYTEST_CURRENT_TEST` environment variable when running tests, which can be inspected

.. code-block:: bash

from each other and thus deriving a canonical import name helps

to avoid surprises such as a test module getting imported twice.

pytest doesn't need to change ``sys.path``, making things much less

surprising.

pytest as a testing framework needs to import test modules and ``conftest.py`` files for execution.

Importing files in Python is a non-trivial process, so aspects of the

these values:

.. _`import-mode-prepend`:

the tests will run against the installed version

with ``prepend``, they would pick up the local version. This kind of confusion is why

we advocate for using :ref:`src-layouts <src-layout>`.

Continue reading