|
| 1 | +Historical Notes |
| 2 | +================ |
| 3 | + |
| 4 | +This page lists features or behavior from previous versions of pytest which have changed over the years. They are |
| 5 | +kept here as a historical note so users looking at old code can find documentation related to them. |
| 6 | + |
| 7 | +cache plugin integrated into the core |
| 8 | +------------------------------------- |
| 9 | + |
| 10 | +.. versionadded:: 2.8 |
| 11 | + |
| 12 | +The functionality of the :ref:`core cache <cache>` plugin was previously distributed |
| 13 | +as a third party plugin named ``pytest-cache``. The core plugin |
| 14 | +is compatible regarding command line options and API usage except that you |
| 15 | +can only store/receive data between test runs that is json-serializable. |
| 16 | + |
| 17 | + |
| 18 | +funcargs and ``pytest_funcarg__`` |
| 19 | +--------------------------------- |
| 20 | + |
| 21 | +.. versionchanged:: 2.3 |
| 22 | + |
| 23 | +In versions prior to 2.3 there was no ``@pytest.fixture`` marker |
| 24 | +and you had to use a magic ``pytest_funcarg__NAME`` prefix |
| 25 | +for the fixture factory. This remains and will remain supported |
| 26 | +but is not anymore advertised as the primary means of declaring fixture |
| 27 | +functions. |
| 28 | + |
| 29 | + |
| 30 | +``@pytest.yield_fixture`` decorator |
| 31 | +----------------------------------- |
| 32 | + |
| 33 | +.. versionchanged:: 2.10 |
| 34 | + |
| 35 | +Prior to version 2.10, in order to use a ``yield`` statement to execute teardown code one |
| 36 | +had to mark a fixture using the ``yield_fixture`` marker. From 2.10 onward, normal |
| 37 | +fixtures can use ``yield`` directly so the ``yield_fixture`` decorator is no longer needed |
| 38 | +and considered deprecated. |
| 39 | + |
| 40 | + |
| 41 | +``[pytest]`` header in ``setup.cfg`` |
| 42 | +------------------------------------ |
| 43 | + |
| 44 | +.. versionchanged:: 3.0 |
| 45 | + |
| 46 | +Prior to 3.0, the supported section name was ``[pytest]``. Due to how |
| 47 | +this may collide with some distutils commands, the recommended |
| 48 | +section name for ``setup.cfg`` files is now ``[tool:pytest]``. |
| 49 | + |
| 50 | +Note that for ``pytest.ini`` and ``tox.ini`` files the section |
| 51 | +name is ``[pytest]``. |
| 52 | + |
| 53 | + |
| 54 | +Applying marks to ``@pytest.mark.parametrize`` parameters |
| 55 | +--------------------------------------------------------- |
| 56 | + |
| 57 | +.. versionchanged:: 3.1 |
| 58 | + |
| 59 | +Prior to version 3.1 the supported mechanism for marking values |
| 60 | +used the syntax:: |
| 61 | + |
| 62 | + import pytest |
| 63 | + @pytest.mark.parametrize("test_input,expected", [ |
| 64 | + ("3+5", 8), |
| 65 | + ("2+4", 6), |
| 66 | + pytest.mark.xfail(("6*9", 42),), |
| 67 | + ]) |
| 68 | + def test_eval(test_input, expected): |
| 69 | + assert eval(test_input) == expected |
| 70 | + |
| 71 | + |
| 72 | +This was an initial hack to support the feature but soon was demonstrated to be incomplete, |
| 73 | +broken for passing functions or applying multiple marks with the same name but different parameters. |
| 74 | + |
| 75 | +The old syntax is planned to be removed in pytest-4.0. |
| 76 | + |
| 77 | + |
| 78 | +``@pytest.mark.parametrize`` argument names as a tuple |
| 79 | +------------------------------------------------------ |
| 80 | + |
| 81 | +.. versionchanged:: 2.4 |
| 82 | + |
| 83 | +In versions prior to 2.4 one needed to specify the argument |
| 84 | +names as a tuple. This remains valid but the simpler ``"name1,name2,..."`` |
| 85 | +comma-separated-string syntax is now advertised first because |
| 86 | +it's easier to write and produces less line noise. |
| 87 | + |
| 88 | + |
| 89 | +setup: is now an "autouse fixture" |
| 90 | +---------------------------------- |
| 91 | + |
| 92 | +.. versionchanged:: 2.3 |
| 93 | + |
| 94 | +During development prior to the pytest-2.3 release the name |
| 95 | +``pytest.setup`` was used but before the release it was renamed |
| 96 | +and moved to become part of the general fixture mechanism, |
| 97 | +namely :ref:`autouse fixtures` |
| 98 | + |
| 99 | + |
| 100 | +.. _string conditions: |
| 101 | + |
| 102 | +Conditions as strings instead of booleans |
| 103 | +----------------------------------------- |
| 104 | + |
| 105 | +.. versionchanged:: 2.4 |
| 106 | + |
| 107 | +Prior to pytest-2.4 the only way to specify skipif/xfail conditions was |
| 108 | +to use strings:: |
| 109 | + |
| 110 | + import sys |
| 111 | + @pytest.mark.skipif("sys.version_info >= (3,3)") |
| 112 | + def test_function(): |
| 113 | + ... |
| 114 | + |
| 115 | +During test function setup the skipif condition is evaluated by calling |
| 116 | +``eval('sys.version_info >= (3,0)', namespace)``. The namespace contains |
| 117 | +all the module globals, and ``os`` and ``sys`` as a minimum. |
| 118 | + |
| 119 | +Since pytest-2.4 :ref:`boolean conditions <condition booleans>` are considered preferable |
| 120 | +because markers can then be freely imported between test modules. |
| 121 | +With strings you need to import not only the marker but all variables |
| 122 | +used by the marker, which violates encapsulation. |
| 123 | + |
| 124 | +The reason for specifying the condition as a string was that ``pytest`` can |
| 125 | +report a summary of skip conditions based purely on the condition string. |
| 126 | +With conditions as booleans you are required to specify a ``reason`` string. |
| 127 | + |
| 128 | +Note that string conditions will remain fully supported and you are free |
| 129 | +to use them if you have no need for cross-importing markers. |
| 130 | + |
| 131 | +The evaluation of a condition string in ``pytest.mark.skipif(conditionstring)`` |
| 132 | +or ``pytest.mark.xfail(conditionstring)`` takes place in a namespace |
| 133 | +dictionary which is constructed as follows: |
| 134 | + |
| 135 | +* the namespace is initialized by putting the ``sys`` and ``os`` modules |
| 136 | + and the pytest ``config`` object into it. |
| 137 | + |
| 138 | +* updated with the module globals of the test function for which the |
| 139 | + expression is applied. |
| 140 | + |
| 141 | +The pytest ``config`` object allows you to skip based on a test |
| 142 | +configuration value which you might have added:: |
| 143 | + |
| 144 | + @pytest.mark.skipif("not config.getvalue('db')") |
| 145 | + def test_function(...): |
| 146 | + ... |
| 147 | + |
| 148 | +The equivalent with "boolean conditions" is:: |
| 149 | + |
| 150 | + @pytest.mark.skipif(not pytest.config.getvalue("db"), |
| 151 | + reason="--db was not specified") |
| 152 | + def test_function(...): |
| 153 | + pass |
| 154 | + |
| 155 | +.. note:: |
| 156 | + |
| 157 | + You cannot use ``pytest.config.getvalue()`` in code |
| 158 | + imported before pytest's argument parsing takes place. For example, |
| 159 | + ``conftest.py`` files are imported before command line parsing and thus |
| 160 | + ``config.getvalue()`` will not execute correctly. |
| 161 | + |
| 162 | +``pytest.set_trace()`` |
| 163 | +---------------------- |
| 164 | + |
| 165 | +.. versionchanged:: 2.4 |
| 166 | + |
| 167 | +Previous to version 2.4 to set a break point in code one needed to use ``pytest.set_trace()``:: |
| 168 | + |
| 169 | + import pytest |
| 170 | + def test_function(): |
| 171 | + ... |
| 172 | + pytest.set_trace() # invoke PDB debugger and tracing |
| 173 | + |
| 174 | + |
| 175 | +This is no longer needed and one can use the native ``import pdb;pdb.set_trace()`` call directly. |
| 176 | + |
| 177 | +For more details see :ref:`breakpoints`. |
0 commit comments