201 lines
6.2 KiB
ReStructuredText
201 lines
6.2 KiB
ReStructuredText
Historical Notes
|
|
================
|
|
|
|
This page lists features or behavior from previous versions of pytest which have changed over the years. They are
|
|
kept here as a historical note so users looking at old code can find documentation related to them.
|
|
|
|
cache plugin integrated into the core
|
|
-------------------------------------
|
|
|
|
.. versionadded:: 2.8
|
|
|
|
The functionality of the :ref:`core cache <cache>` plugin was previously distributed
|
|
as a third party plugin named ``pytest-cache``. The core plugin
|
|
is compatible regarding command line options and API usage except that you
|
|
can only store/receive data between test runs that is json-serializable.
|
|
|
|
|
|
funcargs and ``pytest_funcarg__``
|
|
---------------------------------
|
|
|
|
.. versionchanged:: 2.3
|
|
|
|
In versions prior to 2.3 there was no ``@pytest.fixture`` marker
|
|
and you had to use a magic ``pytest_funcarg__NAME`` prefix
|
|
for the fixture factory. This remains and will remain supported
|
|
but is not anymore advertised as the primary means of declaring fixture
|
|
functions.
|
|
|
|
|
|
``@pytest.yield_fixture`` decorator
|
|
-----------------------------------
|
|
|
|
.. versionchanged:: 2.10
|
|
|
|
Prior to version 2.10, in order to use a ``yield`` statement to execute teardown code one
|
|
had to mark a fixture using the ``yield_fixture`` marker. From 2.10 onward, normal
|
|
fixtures can use ``yield`` directly so the ``yield_fixture`` decorator is no longer needed
|
|
and considered deprecated.
|
|
|
|
|
|
``[pytest]`` header in ``setup.cfg``
|
|
------------------------------------
|
|
|
|
.. versionchanged:: 3.0
|
|
|
|
Prior to 3.0, the supported section name was ``[pytest]``. Due to how
|
|
this may collide with some distutils commands, the recommended
|
|
section name for ``setup.cfg`` files is now ``[tool:pytest]``.
|
|
|
|
Note that for ``pytest.ini`` and ``tox.ini`` files the section
|
|
name is ``[pytest]``.
|
|
|
|
|
|
Applying marks to ``@pytest.mark.parametrize`` parameters
|
|
---------------------------------------------------------
|
|
|
|
.. versionchanged:: 3.1
|
|
|
|
Prior to version 3.1 the supported mechanism for marking values
|
|
used the syntax:
|
|
|
|
.. code-block:: python
|
|
|
|
import pytest
|
|
|
|
|
|
@pytest.mark.parametrize(
|
|
"test_input,expected", [("3+5", 8), ("2+4", 6), pytest.mark.xfail(("6*9", 42))]
|
|
)
|
|
def test_eval(test_input, expected):
|
|
assert eval(test_input) == expected
|
|
|
|
|
|
This was an initial hack to support the feature but soon was demonstrated to be incomplete,
|
|
broken for passing functions or applying multiple marks with the same name but different parameters.
|
|
|
|
The old syntax is planned to be removed in pytest-4.0.
|
|
|
|
|
|
``@pytest.mark.parametrize`` argument names as a tuple
|
|
------------------------------------------------------
|
|
|
|
.. versionchanged:: 2.4
|
|
|
|
In versions prior to 2.4 one needed to specify the argument
|
|
names as a tuple. This remains valid but the simpler ``"name1,name2,..."``
|
|
comma-separated-string syntax is now advertised first because
|
|
it's easier to write and produces less line noise.
|
|
|
|
|
|
setup: is now an "autouse fixture"
|
|
----------------------------------
|
|
|
|
.. versionchanged:: 2.3
|
|
|
|
During development prior to the pytest-2.3 release the name
|
|
``pytest.setup`` was used but before the release it was renamed
|
|
and moved to become part of the general fixture mechanism,
|
|
namely :ref:`autouse fixtures`
|
|
|
|
|
|
.. _string conditions:
|
|
|
|
Conditions as strings instead of booleans
|
|
-----------------------------------------
|
|
|
|
.. versionchanged:: 2.4
|
|
|
|
Prior to pytest-2.4 the only way to specify skipif/xfail conditions was
|
|
to use strings:
|
|
|
|
.. code-block:: python
|
|
|
|
import sys
|
|
|
|
|
|
@pytest.mark.skipif("sys.version_info >= (3,3)")
|
|
def test_function():
|
|
...
|
|
|
|
During test function setup the skipif condition is evaluated by calling
|
|
``eval('sys.version_info >= (3,0)', namespace)``. The namespace contains
|
|
all the module globals, and ``os`` and ``sys`` as a minimum.
|
|
|
|
Since pytest-2.4 :ref:`boolean conditions <condition booleans>` are considered preferable
|
|
because markers can then be freely imported between test modules.
|
|
With strings you need to import not only the marker but all variables
|
|
used by the marker, which violates encapsulation.
|
|
|
|
The reason for specifying the condition as a string was that ``pytest`` can
|
|
report a summary of skip conditions based purely on the condition string.
|
|
With conditions as booleans you are required to specify a ``reason`` string.
|
|
|
|
Note that string conditions will remain fully supported and you are free
|
|
to use them if you have no need for cross-importing markers.
|
|
|
|
The evaluation of a condition string in ``pytest.mark.skipif(conditionstring)``
|
|
or ``pytest.mark.xfail(conditionstring)`` takes place in a namespace
|
|
dictionary which is constructed as follows:
|
|
|
|
* the namespace is initialized by putting the ``sys`` and ``os`` modules
|
|
and the pytest ``config`` object into it.
|
|
|
|
* updated with the module globals of the test function for which the
|
|
expression is applied.
|
|
|
|
The pytest ``config`` object allows you to skip based on a test
|
|
configuration value which you might have added:
|
|
|
|
.. code-block:: python
|
|
|
|
@pytest.mark.skipif("not config.getvalue('db')")
|
|
def test_function():
|
|
...
|
|
|
|
The equivalent with "boolean conditions" is:
|
|
|
|
.. code-block:: python
|
|
|
|
@pytest.mark.skipif(not pytest.config.getvalue("db"), reason="--db was not specified")
|
|
def test_function():
|
|
pass
|
|
|
|
.. note::
|
|
|
|
You cannot use ``pytest.config.getvalue()`` in code
|
|
imported before pytest's argument parsing takes place. For example,
|
|
``conftest.py`` files are imported before command line parsing and thus
|
|
``config.getvalue()`` will not execute correctly.
|
|
|
|
``pytest.set_trace()``
|
|
----------------------
|
|
|
|
.. versionchanged:: 2.4
|
|
|
|
Previous to version 2.4 to set a break point in code one needed to use ``pytest.set_trace()``:
|
|
|
|
.. code-block:: python
|
|
|
|
import pytest
|
|
|
|
|
|
def test_function():
|
|
...
|
|
pytest.set_trace() # invoke PDB debugger and tracing
|
|
|
|
|
|
This is no longer needed and one can use the native ``import pdb;pdb.set_trace()`` call directly.
|
|
|
|
For more details see :ref:`breakpoints`.
|
|
|
|
"compat" properties
|
|
-------------------
|
|
|
|
.. deprecated:: 3.9
|
|
|
|
Access of ``Module``, ``Function``, ``Class``, ``Instance``, ``File`` and ``Item`` through ``Node`` instances have long
|
|
been documented as deprecated, but started to emit warnings from pytest ``3.9`` and onward.
|
|
|
|
Users should just ``import pytest`` and access those objects using the ``pytest`` module.
|