Merge pull request #5210 from nicoddemus/merge-master-into-features
Merge master into features
This commit is contained in:
Daniel Hahler
GitHub
commit
f5c1f3df71
1
AUTHORS
1
AUTHORS
|
|
@ -59,6 +59,7 @@ Christopher Gilling
|
|||
Christopher Dignam
|
||||
CrazyMerlyn
|
||||
Cyrus Maden
|
||||
Damian Skrzypczak
|
||||
Dhiren Serai
|
||||
Daniel Grana
|
||||
Daniel Hahler
|
||||
|
|
|
|||
|
|
@ -43,10 +43,10 @@ jobs:
|
|||
# But no exception with py27-pexpect,py27-twisted,py27-numpy.
|
||||
PYTEST_COVERAGE: '1'
|
||||
pypy:
|
||||
python.version: 'pypy'
|
||||
python.version: 'pypy2'
|
||||
tox.env: 'pypy'
|
||||
python.exe: 'pypy'
|
||||
# NOTE: pypy3 fails to install pip currently due to an interal error.
|
||||
# NOTE: pypy3 fails to install pip currently due to an internal error.
|
||||
# pypy3:
|
||||
# python.version: 'pypy3'
|
||||
# tox.env: 'pypy3'
|
||||
|
|
@ -86,7 +86,6 @@ jobs:
|
|||
|
||||
steps:
|
||||
- task: UsePythonVersion@0
|
||||
condition: not(startsWith(variables['python.exe'], 'pypy'))
|
||||
inputs:
|
||||
versionSpec: '$(python.version)'
|
||||
architecture: 'x64'
|
||||
|
|
@ -95,23 +94,6 @@ jobs:
|
|||
condition: eq(variables['python.needs_vc'], True)
|
||||
displayName: 'Install VC for py27'
|
||||
|
||||
- script: choco install python.pypy
|
||||
condition: eq(variables['python.exe'], 'pypy')
|
||||
displayName: 'Install pypy'
|
||||
|
||||
- script: choco install pypy3
|
||||
condition: eq(variables['python.exe'], 'pypy3')
|
||||
displayName: 'Install pypy3'
|
||||
|
||||
- task: PowerShell@2
|
||||
inputs:
|
||||
targetType: 'inline'
|
||||
script: |
|
||||
Invoke-WebRequest -Uri "https://bootstrap.pypa.io/get-pip.py" -OutFile "get-pip.py"
|
||||
$(python.exe) get-pip.py
|
||||
condition: startsWith(variables['python.exe'], 'pypy')
|
||||
displayName: 'Install pip'
|
||||
|
||||
- script: $(python.exe) -m pip install --upgrade pip && $(python.exe) -m pip install tox
|
||||
displayName: 'Install tox'
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
Doc: ``pytest_ignore_collect``, ``pytest_collect_directory``, ``pytest_collect_file`` and ``pytest_pycollect_makemodule`` hooks's 'path' parameter documented type is now ``py.path.local``
|
||||
|
|
@ -0,0 +1 @@
|
|||
Removed internal and unused ``_pytest.deprecated.MARK_INFO_ATTRIBUTE``.
|
||||
|
|
@ -0,0 +1 @@
|
|||
Improve help for ``--runxfail`` flag.
|
||||
|
|
@ -154,7 +154,7 @@ or bugs in dependencies.
|
|||
Assertions about expected warnings
|
||||
-----------------------------------------
|
||||
|
||||
.. versionadded:: 2.8
|
||||
|
||||
|
||||
You can check that code raises a particular warning using
|
||||
:ref:`pytest.warns <warns>`.
|
||||
|
|
@ -165,7 +165,7 @@ You can check that code raises a particular warning using
|
|||
Making use of context-sensitive comparisons
|
||||
-------------------------------------------------
|
||||
|
||||
.. versionadded:: 2.0
|
||||
|
||||
|
||||
``pytest`` has rich support for providing context-sensitive information
|
||||
when it encounters comparisons. For example:
|
||||
|
|
@ -284,7 +284,7 @@ the conftest file:
|
|||
Assertion introspection details
|
||||
-------------------------------
|
||||
|
||||
.. versionadded:: 2.1
|
||||
|
||||
|
||||
|
||||
Reporting details about a failing assertion is achieved by rewriting assert
|
||||
|
|
@ -335,13 +335,13 @@ If this is the case you have two options:
|
|||
* Disable rewriting for all modules by using ``--assert=plain``.
|
||||
|
||||
|
||||
.. versionadded:: 2.1
|
||||
|
||||
Add assert rewriting as an alternate introspection technique.
|
||||
|
||||
.. versionchanged:: 2.1
|
||||
|
||||
Introduce the ``--assert`` option. Deprecate ``--no-assert`` and
|
||||
``--nomagic``.
|
||||
|
||||
.. versionchanged:: 3.0
|
||||
|
||||
Removes the ``--no-assert`` and ``--nomagic`` options.
|
||||
Removes the ``--assert=reinterp`` option.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
Cache: working with cross-testrun state
|
||||
=======================================
|
||||
|
||||
.. versionadded:: 2.8
|
||||
|
||||
|
||||
Usage
|
||||
---------
|
||||
|
|
|
|||
|
|
@ -121,11 +121,11 @@ same interface but allows to also capture output from
|
|||
libraries or subprocesses that directly write to operating
|
||||
system level output streams (FD1 and FD2).
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
The return value from ``readouterr`` changed to a ``namedtuple`` with two attributes, ``out`` and ``err``.
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
If the code under test writes non-textual data, you can capture this using
|
||||
the ``capsysbinary`` fixture which instead returns ``bytes`` from
|
||||
|
|
@ -133,7 +133,7 @@ the ``readouterr`` method. The ``capfsysbinary`` fixture is currently only
|
|||
available in python 3.
|
||||
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
If the code under test writes non-textual data, you can capture this using
|
||||
the ``capfdbinary`` fixture which instead returns ``bytes`` from
|
||||
|
|
@ -141,7 +141,7 @@ the ``readouterr`` method. The ``capfdbinary`` fixture operates on the
|
|||
filedescriptor level.
|
||||
|
||||
|
||||
.. versionadded:: 3.0
|
||||
|
||||
|
||||
To temporarily disable capture within a test, both ``capsys``
|
||||
and ``capfd`` have a ``disabled()`` method that can be used
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ which were registered by installed plugins.
|
|||
Initialization: determining rootdir and inifile
|
||||
-----------------------------------------------
|
||||
|
||||
.. versionadded:: 2.7
|
||||
|
||||
|
||||
pytest determines a ``rootdir`` for each test run which depends on
|
||||
the command line arguments (specified test files, paths) and on
|
||||
|
|
@ -90,7 +90,7 @@ The ``config`` object will subsequently carry these attributes:
|
|||
|
||||
- ``config.inifile``: the determined ini-file, may be ``None``.
|
||||
|
||||
The rootdir is used a reference directory for constructing test
|
||||
The rootdir is used as a reference directory for constructing test
|
||||
addresses ("nodeids") and can be used also by plugins for storing
|
||||
per-testrun information.
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,8 @@ If you still have concerns about this deprecation and future removal, please com
|
|||
|
||||
The ``pytest.config`` global object is deprecated. Instead use
|
||||
``request.config`` (via the ``request`` fixture) or if you are a plugin author
|
||||
use the ``pytest_configure(config)`` hook.
|
||||
use the ``pytest_configure(config)`` hook. Note that many hooks can also access
|
||||
the ``config`` object indirectly, through ``session.config`` or ``item.config`` for example.
|
||||
|
||||
.. _raises-warns-exec:
|
||||
|
||||
|
|
@ -104,7 +105,7 @@ Becomes:
|
|||
Result log (``--result-log``)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. deprecated:: 3.0
|
||||
|
||||
|
||||
The ``--resultlog`` command line option has been deprecated: it is little used
|
||||
and there are more modern and better alternatives, for example `pytest-tap <https://tappy.readthedocs.io/en/latest/>`_.
|
||||
|
|
|
|||
|
|
@ -10,29 +10,63 @@ can change the pattern by issuing:
|
|||
|
||||
pytest --doctest-glob='*.rst'
|
||||
|
||||
on the command line. Since version ``2.9``, ``--doctest-glob``
|
||||
can be given multiple times in the command-line.
|
||||
on the command line. ``--doctest-glob`` can be given multiple times in the command-line.
|
||||
|
||||
.. versionadded:: 3.1
|
||||
If you then have a text file like this:
|
||||
|
||||
You can specify the encoding that will be used for those doctest files
|
||||
using the ``doctest_encoding`` ini option:
|
||||
.. code-block:: text
|
||||
|
||||
.. code-block:: ini
|
||||
# content of test_example.txt
|
||||
|
||||
# content of pytest.ini
|
||||
[pytest]
|
||||
doctest_encoding = latin1
|
||||
hello this is a doctest
|
||||
>>> x = 3
|
||||
>>> x
|
||||
3
|
||||
|
||||
The default encoding is UTF-8.
|
||||
then you can just invoke ``pytest`` directly:
|
||||
|
||||
You can also trigger running of doctests
|
||||
from docstrings in all python modules (including regular
|
||||
python test modules):
|
||||
.. code-block:: pytest
|
||||
|
||||
$ pytest
|
||||
=========================== test session starts ============================
|
||||
platform linux -- Python 3.x.y, pytest-4.x.y, py-1.x.y, pluggy-0.x.y
|
||||
cachedir: $PYTHON_PREFIX/.pytest_cache
|
||||
rootdir: $REGENDOC_TMPDIR
|
||||
collected 1 item
|
||||
|
||||
test_example.txt . [100%]
|
||||
|
||||
========================= 1 passed in 0.12 seconds =========================
|
||||
|
||||
By default, pytest will collect ``test*.txt`` files looking for doctest directives, but you
|
||||
can pass additional globs using the ``--doctest-glob`` option (multi-allowed).
|
||||
|
||||
In addition to text files, you can also execute doctests directly from docstrings of your classes
|
||||
and functions, including from test modules:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
# content of mymodule.py
|
||||
def something():
|
||||
""" a doctest in a docstring
|
||||
>>> something()
|
||||
42
|
||||
"""
|
||||
return 42
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pytest --doctest-modules
|
||||
$ pytest --doctest-modules
|
||||
=========================== test session starts ============================
|
||||
platform linux -- Python 3.x.y, pytest-4.x.y, py-1.x.y, pluggy-0.x.y
|
||||
cachedir: $PYTHON_PREFIX/.pytest_cache
|
||||
rootdir: $REGENDOC_TMPDIR
|
||||
collected 2 items
|
||||
|
||||
mymodule.py . [ 50%]
|
||||
test_example.txt . [100%]
|
||||
|
||||
========================= 2 passed in 0.12 seconds =========================
|
||||
|
||||
You can make these changes permanent in your project by
|
||||
putting them into a pytest.ini file like this:
|
||||
|
|
@ -43,57 +77,37 @@ putting them into a pytest.ini file like this:
|
|||
[pytest]
|
||||
addopts = --doctest-modules
|
||||
|
||||
If you then have a text file like this:
|
||||
.. note::
|
||||
|
||||
.. code-block:: text
|
||||
The builtin pytest doctest supports only ``doctest`` blocks, but if you are looking
|
||||
for more advanced checking over *all* your documentation,
|
||||
including doctests, ``.. codeblock:: python`` Sphinx directive support,
|
||||
and any other examples your documentation may include, you may wish to
|
||||
consider `Sybil <https://sybil.readthedocs.io/en/latest/index.html>`__.
|
||||
It provides pytest integration out of the box.
|
||||
|
||||
# content of example.rst
|
||||
|
||||
hello this is a doctest
|
||||
>>> x = 3
|
||||
>>> x
|
||||
3
|
||||
Encoding
|
||||
--------
|
||||
|
||||
and another like this::
|
||||
The default encoding is **UTF-8**, but you can specify the encoding
|
||||
that will be used for those doctest files using the
|
||||
``doctest_encoding`` ini option:
|
||||
|
||||
# content of mymodule.py
|
||||
def something():
|
||||
""" a doctest in a docstring
|
||||
>>> something()
|
||||
42
|
||||
"""
|
||||
return 42
|
||||
.. code-block:: ini
|
||||
|
||||
then you can just invoke ``pytest`` without command line options:
|
||||
# content of pytest.ini
|
||||
[pytest]
|
||||
doctest_encoding = latin1
|
||||
|
||||
.. code-block:: pytest
|
||||
Using 'doctest' options
|
||||
-----------------------
|
||||
|
||||
$ pytest
|
||||
=========================== test session starts ============================
|
||||
platform linux -- Python 3.x.y, pytest-4.x.y, py-1.x.y, pluggy-0.x.y
|
||||
cachedir: $PYTHON_PREFIX/.pytest_cache
|
||||
rootdir: $REGENDOC_TMPDIR, inifile: pytest.ini
|
||||
collected 1 item
|
||||
The standard ``doctest`` module provides some `options <https://docs.python.org/3/library/doctest.html#option-flags>`__
|
||||
to configure the strictness of doctest tests. In pytest, you can enable those flags using the
|
||||
configuration file.
|
||||
|
||||
mymodule.py . [100%]
|
||||
|
||||
========================= 1 passed in 0.12 seconds =========================
|
||||
|
||||
It is possible to use fixtures using the ``getfixture`` helper:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
# content of example.rst
|
||||
>>> tmp = getfixture('tmpdir')
|
||||
>>> ...
|
||||
>>>
|
||||
|
||||
Also, :ref:`usefixtures` and :ref:`autouse` fixtures are supported
|
||||
when executing text doctest files.
|
||||
|
||||
The standard ``doctest`` module provides some setting flags to configure the
|
||||
strictness of doctest tests. In pytest, you can enable those flags using the
|
||||
configuration file. To make pytest ignore trailing whitespaces and ignore
|
||||
For example, to make pytest ignore trailing whitespaces and ignore
|
||||
lengthy exception stack traces you can just write:
|
||||
|
||||
.. code-block:: ini
|
||||
|
|
@ -110,16 +124,7 @@ Python 3 unchanged:
|
|||
* ``ALLOW_BYTES``: when enabled, the ``b`` prefix is stripped from byte strings
|
||||
in expected doctest output.
|
||||
|
||||
As with any other option flag, these flags can be enabled in ``pytest.ini`` using
|
||||
the ``doctest_optionflags`` ini option:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[pytest]
|
||||
doctest_optionflags = ALLOW_UNICODE ALLOW_BYTES
|
||||
|
||||
|
||||
Alternatively, it can be enabled by an inline comment in the doc test
|
||||
Alternatively, options can be enabled by an inline comment in the doc test
|
||||
itself:
|
||||
|
||||
.. code-block:: rst
|
||||
|
|
@ -128,7 +133,7 @@ itself:
|
|||
>>> get_unicode_greeting() # doctest: +ALLOW_UNICODE
|
||||
'Hello'
|
||||
|
||||
By default, pytest would report only the first failure for a given doctest. If
|
||||
By default, pytest would report only the first failure for a given doctest. If
|
||||
you want to continue the test even when you have failures, do:
|
||||
|
||||
.. code-block:: bash
|
||||
|
|
@ -136,12 +141,50 @@ you want to continue the test even when you have failures, do:
|
|||
pytest --doctest-modules --doctest-continue-on-failure
|
||||
|
||||
|
||||
Output format
|
||||
-------------
|
||||
|
||||
You can change the diff output format on failure for your doctests
|
||||
by using one of standard doctest modules format in options
|
||||
(see :data:`python:doctest.REPORT_UDIFF`, :data:`python:doctest.REPORT_CDIFF`,
|
||||
:data:`python:doctest.REPORT_NDIFF`, :data:`python:doctest.REPORT_ONLY_FIRST_FAILURE`):
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pytest --doctest-modules --doctest-report none
|
||||
pytest --doctest-modules --doctest-report udiff
|
||||
pytest --doctest-modules --doctest-report cdiff
|
||||
pytest --doctest-modules --doctest-report ndiff
|
||||
pytest --doctest-modules --doctest-report only_first_failure
|
||||
|
||||
|
||||
pytest-specific features
|
||||
------------------------
|
||||
|
||||
Some features are provided to make writing doctests easier or with better integration with
|
||||
your existing test suite. Keep in mind however that by using those features you will make
|
||||
your doctests incompatible with the standard ``doctests`` module.
|
||||
|
||||
Using fixtures
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
It is possible to use fixtures using the ``getfixture`` helper:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
# content of example.rst
|
||||
>>> tmp = getfixture('tmpdir')
|
||||
>>> ...
|
||||
>>>
|
||||
|
||||
Also, :ref:`usefixtures` and :ref:`autouse` fixtures are supported
|
||||
when executing text doctest files.
|
||||
|
||||
|
||||
.. _`doctest_namespace`:
|
||||
|
||||
The 'doctest_namespace' fixture
|
||||
-------------------------------
|
||||
|
||||
.. versionadded:: 3.0
|
||||
'doctest_namespace' fixture
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The ``doctest_namespace`` fixture can be used to inject items into the
|
||||
namespace in which your doctests run. It is intended to be used within
|
||||
|
|
@ -171,20 +214,14 @@ Note that like the normal ``conftest.py``, the fixtures are discovered in the di
|
|||
Meaning that if you put your doctest with your source code, the relevant conftest.py needs to be in the same directory tree.
|
||||
Fixtures will not be discovered in a sibling directory tree!
|
||||
|
||||
Output format
|
||||
-------------
|
||||
Skipping tests dynamically
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 3.0
|
||||
.. versionadded:: 4.4
|
||||
|
||||
You can change the diff output format on failure for your doctests
|
||||
by using one of standard doctest modules format in options
|
||||
(see :data:`python:doctest.REPORT_UDIFF`, :data:`python:doctest.REPORT_CDIFF`,
|
||||
:data:`python:doctest.REPORT_NDIFF`, :data:`python:doctest.REPORT_ONLY_FIRST_FAILURE`):
|
||||
You can use ``pytest.skip`` to dynamically skip doctests. For example::
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pytest --doctest-modules --doctest-report none
|
||||
pytest --doctest-modules --doctest-report udiff
|
||||
pytest --doctest-modules --doctest-report cdiff
|
||||
pytest --doctest-modules --doctest-report ndiff
|
||||
pytest --doctest-modules --doctest-report only_first_failure
|
||||
>>> import sys, pytest
|
||||
>>> if sys.platform.startswith('win'):
|
||||
... pytest.skip('this doctest does not work on Windows')
|
||||
...
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ You can "mark" a test function with custom metadata like this:
|
|||
def test_method(self):
|
||||
pass
|
||||
|
||||
.. versionadded:: 2.2
|
||||
|
||||
|
||||
You can then restrict a test run to only run tests marked with ``webtest``:
|
||||
|
||||
|
|
@ -210,7 +210,7 @@ Or to select "http" and "quick" tests:
|
|||
Registering markers
|
||||
-------------------------------------
|
||||
|
||||
.. versionadded:: 2.2
|
||||
|
||||
|
||||
.. ini-syntax for custom markers:
|
||||
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ the command line arguments before they get processed:
|
|||
|
||||
.. code-block:: python
|
||||
|
||||
# content of conftest.py
|
||||
# setuptools plugin
|
||||
import sys
|
||||
|
||||
|
||||
|
|
@ -854,7 +854,7 @@ information.
|
|||
``PYTEST_CURRENT_TEST`` environment variable
|
||||
--------------------------------------------
|
||||
|
||||
.. versionadded:: 3.2
|
||||
|
||||
|
||||
Sometimes a test session might get stuck and there might be no easy way to figure out
|
||||
which test got stuck, for example if pytest was run in quiet mode (``-q``) or you don't have access to the console
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ pytest fixtures: explicit, modular, scalable
|
|||
|
||||
.. currentmodule:: _pytest.python
|
||||
|
||||
.. versionadded:: 2.0/2.3/2.4
|
||||
|
||||
|
||||
.. _`xUnit`: http://en.wikipedia.org/wiki/XUnit
|
||||
.. _`purpose of test fixtures`: http://en.wikipedia.org/wiki/Test_fixture#Software
|
||||
|
|
@ -276,7 +276,7 @@ Finally, the ``class`` scope will invoke the fixture once per test *class*.
|
|||
``package`` scope (experimental)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 3.7
|
||||
|
||||
|
||||
In pytest 3.7 the ``package`` scope has been introduced. Package-scoped fixtures
|
||||
are finalized when the last test of a *package* finishes.
|
||||
|
|
@ -292,7 +292,7 @@ are finalized when the last test of a *package* finishes.
|
|||
Higher-scoped fixtures are instantiated first
|
||||
---------------------------------------------
|
||||
|
||||
.. versionadded:: 3.5
|
||||
|
||||
|
||||
Within a function request for features, fixture of higher-scopes (such as ``session``) are instantiated first than
|
||||
lower-scoped fixtures (such as ``function`` or ``class``). The relative order of fixtures of same scope follows
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ kept here as a historical note so users looking at old code can find documentati
|
|||
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
|
||||
|
|
@ -18,7 +18,7 @@ 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
|
||||
|
|
@ -30,7 +30,7 @@ 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
|
||||
|
|
@ -41,7 +41,7 @@ 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
|
||||
|
|
@ -54,7 +54,7 @@ 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:
|
||||
|
|
@ -80,7 +80,7 @@ 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,..."``
|
||||
|
|
@ -91,7 +91,7 @@ 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
|
||||
|
|
@ -104,7 +104,7 @@ namely :ref:`autouse fixtures`
|
|||
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:
|
||||
|
|
@ -171,7 +171,7 @@ The equivalent with "boolean conditions" is:
|
|||
``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()``:
|
||||
|
||||
|
|
@ -192,7 +192,7 @@ 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.
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@
|
|||
Logging
|
||||
-------
|
||||
|
||||
.. versionadded:: 3.3
|
||||
.. versionchanged:: 3.4
|
||||
|
||||
|
||||
|
||||
pytest captures log messages of level ``WARNING`` or above automatically and displays them in their own section
|
||||
for each failed test in the same manner as captured stdout and stderr.
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ so that they appear in pytest's help text and do not emit warnings.
|
|||
Marker revamp and iteration
|
||||
---------------------------
|
||||
|
||||
.. versionadded:: 3.6
|
||||
|
||||
|
||||
pytest's marker implementation traditionally worked by simply updating the ``__dict__`` attribute of functions to cumulatively add markers. As a result, markers would unintentionally be passed along class hierarchies in surprising ways. Further, the API for retrieving them was inconsistent, as markers from parameterization would be stored differently than markers applied using the ``@pytest.mark`` decorator and markers added via ``node.add_marker``.
|
||||
|
||||
|
|
|
|||
|
|
@ -29,8 +29,8 @@ pytest enables test parametrization at several levels:
|
|||
|
||||
.. regendoc: wipe
|
||||
|
||||
.. versionadded:: 2.2
|
||||
.. versionchanged:: 2.4
|
||||
|
||||
|
||||
Several improvements.
|
||||
|
||||
The builtin :ref:`pytest.mark.parametrize ref` decorator enables
|
||||
|
|
|
|||
|
|
@ -983,7 +983,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: cache_dir
|
||||
|
||||
.. versionadded:: 3.2
|
||||
|
||||
|
||||
Sets a directory where stores content of cache plugin. Default directory is
|
||||
``.pytest_cache`` which is created in :ref:`rootdir <rootdir>`. Directory may be
|
||||
|
|
@ -1003,7 +1003,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: console_output_style
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
Sets the console output style while running tests:
|
||||
|
||||
|
|
@ -1023,7 +1023,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: doctest_encoding
|
||||
|
||||
.. versionadded:: 3.1
|
||||
|
||||
|
||||
Default encoding to use to decode text files with docstrings.
|
||||
:doc:`See how pytest handles doctests <doctest>`.
|
||||
|
|
@ -1037,7 +1037,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: empty_parameter_set_mark
|
||||
|
||||
.. versionadded:: 3.4
|
||||
|
||||
|
||||
Allows to pick the action for empty parametersets in parameterization
|
||||
|
||||
|
|
@ -1060,7 +1060,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: filterwarnings
|
||||
|
||||
.. versionadded:: 3.1
|
||||
|
||||
|
||||
Sets a list of filters and actions that should be taken for matched
|
||||
warnings. By default all warnings emitted during the test session
|
||||
|
|
@ -1094,7 +1094,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: junit_suite_name
|
||||
|
||||
.. versionadded:: 3.1
|
||||
|
||||
|
||||
To set the name of the root test suite xml item, you can configure the ``junit_suite_name`` option in your config file:
|
||||
|
||||
|
|
@ -1106,7 +1106,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: log_cli_date_format
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
Sets a :py:func:`time.strftime`-compatible string that will be used when formatting dates for live logging.
|
||||
|
||||
|
|
@ -1119,7 +1119,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: log_cli_format
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
Sets a :py:mod:`logging`-compatible string used to format live logging messages.
|
||||
|
||||
|
|
@ -1133,7 +1133,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: log_cli_level
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
Sets the minimum log message level that should be captured for live logging. The integer value or
|
||||
the names of the levels can be used.
|
||||
|
|
@ -1148,7 +1148,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: log_date_format
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
Sets a :py:func:`time.strftime`-compatible string that will be used when formatting dates for logging capture.
|
||||
|
||||
|
|
@ -1162,7 +1162,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: log_file
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
Sets a file name relative to the ``pytest.ini`` file where log messages should be written to, in addition
|
||||
to the other logging facilities that are active.
|
||||
|
|
@ -1177,7 +1177,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: log_file_date_format
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
Sets a :py:func:`time.strftime`-compatible string that will be used when formatting dates for the logging file.
|
||||
|
||||
|
|
@ -1190,7 +1190,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: log_file_format
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
Sets a :py:mod:`logging`-compatible string used to format logging messages redirected to the logging file.
|
||||
|
||||
|
|
@ -1203,7 +1203,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: log_file_level
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
Sets the minimum log message level that should be captured for the logging file. The integer value or
|
||||
the names of the levels can be used.
|
||||
|
|
@ -1218,7 +1218,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: log_format
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
Sets a :py:mod:`logging`-compatible string used to format captured logging messages.
|
||||
|
||||
|
|
@ -1232,7 +1232,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: log_level
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
Sets the minimum log message level that should be captured for logging capture. The integer value or
|
||||
the names of the levels can be used.
|
||||
|
|
@ -1247,7 +1247,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: log_print
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
If set to ``False``, will disable displaying captured logging messages for failed tests.
|
||||
|
||||
|
|
@ -1384,7 +1384,7 @@ passed multiple times. The expected format is ``name=value``. For example::
|
|||
|
||||
.. confval:: testpaths
|
||||
|
||||
.. versionadded:: 2.8
|
||||
|
||||
|
||||
Sets list of directories that should be searched for tests when
|
||||
no specific directories, files or test ids are given in the command line when
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ More details on the ``-r`` option can be found by running ``pytest -h``.
|
|||
Skipping test functions
|
||||
-----------------------
|
||||
|
||||
.. versionadded:: 2.9
|
||||
|
||||
|
||||
The simplest way to skip a test function is to mark it with the ``skip`` decorator
|
||||
which may be passed an optional ``reason``:
|
||||
|
|
@ -80,7 +80,7 @@ It is also possible to skip the whole module using
|
|||
``skipif``
|
||||
~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 2.0
|
||||
|
||||
|
||||
If you wish to skip something conditionally then you can use ``skipif`` instead.
|
||||
Here is an example of marking a test function to be skipped
|
||||
|
|
@ -254,7 +254,7 @@ internally by raising a known exception.
|
|||
``strict`` parameter
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 2.9
|
||||
|
||||
|
||||
Both ``XFAIL`` and ``XPASS`` don't fail the test suite, unless the ``strict`` keyword-only
|
||||
parameter is passed as ``True``:
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Temporary directories and files
|
|||
The ``tmp_path`` fixture
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 3.9
|
||||
|
||||
|
||||
|
||||
You can use the ``tmp_path`` fixture which will
|
||||
|
|
@ -71,7 +71,7 @@ Running this would result in a passed test except for the last
|
|||
The ``tmp_path_factory`` fixture
|
||||
--------------------------------
|
||||
|
||||
.. versionadded:: 3.9
|
||||
|
||||
|
||||
|
||||
The ``tmp_path_factory`` is a session-scoped fixture which can be used
|
||||
|
|
@ -136,7 +136,7 @@ Running this would result in a passed test except for the last
|
|||
The 'tmpdir_factory' fixture
|
||||
----------------------------
|
||||
|
||||
.. versionadded:: 2.8
|
||||
|
||||
|
||||
The ``tmpdir_factory`` is a session-scoped fixture which can be used
|
||||
to create arbitrary temporary directories from any other fixture or test.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Usage and Invocations
|
|||
Calling pytest through ``python -m pytest``
|
||||
-----------------------------------------------------
|
||||
|
||||
.. versionadded:: 2.0
|
||||
|
||||
|
||||
You can invoke testing through the Python interpreter from the command line:
|
||||
|
||||
|
|
@ -155,7 +155,7 @@ option you make sure a trace is shown.
|
|||
Detailed summary report
|
||||
-----------------------
|
||||
|
||||
.. versionadded:: 2.9
|
||||
|
||||
|
||||
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.
|
||||
|
|
@ -430,7 +430,7 @@ integration servers, use this invocation:
|
|||
|
||||
to create an XML file at ``path``.
|
||||
|
||||
.. versionadded:: 3.1
|
||||
|
||||
|
||||
To set the name of the root test suite xml item, you can configure the ``junit_suite_name`` option in your config file:
|
||||
|
||||
|
|
@ -458,8 +458,8 @@ instead, configure the ``junit_duration_report`` option like this:
|
|||
record_property
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 2.8
|
||||
.. versionchanged:: 3.5
|
||||
|
||||
|
||||
|
||||
Fixture renamed from ``record_xml_property`` to ``record_property`` as user
|
||||
properties are now available to all reporters.
|
||||
|
|
@ -530,7 +530,7 @@ Will result in:
|
|||
record_xml_attribute
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 3.4
|
||||
|
||||
|
||||
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:
|
||||
|
|
@ -590,7 +590,7 @@ Instead, this will add an attribute ``assertions="REQ-1234"`` inside the generat
|
|||
LogXML: add_global_property
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 3.0
|
||||
|
||||
|
||||
If you want to add a properties node in the testsuite level, which may contains properties that are relevant
|
||||
to all testcases you can use ``LogXML.add_global_properties``
|
||||
|
|
@ -640,7 +640,7 @@ This will add a property node below the testsuite node to the generated xml:
|
|||
Creating resultlog format files
|
||||
----------------------------------------------------
|
||||
|
||||
.. deprecated:: 3.0
|
||||
|
||||
|
||||
This option is rarely used and is scheduled for removal in 5.0.
|
||||
|
||||
|
|
@ -714,7 +714,7 @@ executing doctest tests from text files, invoke pytest like this:
|
|||
Calling pytest from Python code
|
||||
----------------------------------------------------
|
||||
|
||||
.. versionadded:: 2.0
|
||||
|
||||
|
||||
You can invoke ``pytest`` from Python code directly::
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Warnings Capture
|
||||
================
|
||||
|
||||
.. versionadded:: 3.1
|
||||
|
||||
|
||||
Starting from version ``3.1``, pytest now automatically catches warnings during test execution
|
||||
and displays them at the end of the session:
|
||||
|
|
@ -90,7 +90,7 @@ documentation for other examples and advanced usage.
|
|||
``@pytest.mark.filterwarnings``
|
||||
-------------------------------
|
||||
|
||||
.. versionadded:: 3.2
|
||||
|
||||
|
||||
You can use the ``@pytest.mark.filterwarnings`` to add warning filters to specific test items,
|
||||
allowing you to have finer control of which warnings should be captured at test, class or
|
||||
|
|
@ -156,8 +156,8 @@ using an external system.
|
|||
DeprecationWarning and PendingDeprecationWarning
|
||||
------------------------------------------------
|
||||
|
||||
.. versionadded:: 3.8
|
||||
.. versionchanged:: 3.9
|
||||
|
||||
|
||||
|
||||
By default pytest will display ``DeprecationWarning`` and ``PendingDeprecationWarning`` warnings from
|
||||
user code and third-party libraries, as recommended by `PEP-0565 <https://www.python.org/dev/peps/pep-0565>`_.
|
||||
|
|
@ -247,7 +247,7 @@ You can also use it as a contextmanager:
|
|||
Asserting warnings with the warns function
|
||||
------------------------------------------
|
||||
|
||||
.. versionadded:: 2.8
|
||||
|
||||
|
||||
You can check that code raises a particular warning using ``pytest.warns``,
|
||||
which works in a similar manner to :ref:`raises <assertraises>`:
|
||||
|
|
@ -377,7 +377,7 @@ custom error message.
|
|||
Internal pytest warnings
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 3.8
|
||||
|
||||
|
||||
pytest may generate its own warnings in some situations, such as improper usage or deprecated features.
|
||||
|
||||
|
|
|
|||
|
|
@ -515,7 +515,7 @@ hookwrapper: executing around other hooks
|
|||
|
||||
.. currentmodule:: _pytest.core
|
||||
|
||||
.. versionadded:: 2.7
|
||||
|
||||
|
||||
pytest plugins can implement hook wrappers which wrap the execution
|
||||
of other hook implementations. A hook wrapper is a generator function
|
||||
|
|
|
|||
|
|
@ -5,9 +5,9 @@
|
|||
"yield_fixture" functions
|
||||
---------------------------------------------------------------
|
||||
|
||||
.. deprecated:: 3.0
|
||||
|
||||
.. versionadded:: 2.4
|
||||
|
||||
|
||||
|
||||
.. important::
|
||||
Since pytest-3.0, fixtures using the normal ``fixture`` decorator can use a ``yield``
|
||||
|
|
|
|||
|
|
@ -48,12 +48,6 @@ RESULT_LOG = PytestDeprecationWarning(
|
|||
"See https://docs.pytest.org/en/latest/deprecations.html#result-log-result-log for more information."
|
||||
)
|
||||
|
||||
MARK_INFO_ATTRIBUTE = RemovedInPytest4Warning(
|
||||
"MarkInfo objects are deprecated as they contain merged marks which are hard to deal with correctly.\n"
|
||||
"Please use node.get_closest_marker(name) or node.iter_markers(name).\n"
|
||||
"Docs: https://docs.pytest.org/en/latest/mark.html#updating-code"
|
||||
)
|
||||
|
||||
RAISES_EXEC = PytestDeprecationWarning(
|
||||
"raises(..., 'code(as_a_string)') is deprecated, use the context manager form or use `exec()` directly\n\n"
|
||||
"See https://docs.pytest.org/en/latest/deprecations.html#raises-warns-exec"
|
||||
|
|
|
|||
|
|
@ -188,7 +188,7 @@ def pytest_ignore_collect(path, config):
|
|||
|
||||
Stops at first non-None result, see :ref:`firstresult`
|
||||
|
||||
:param str path: the path to analyze
|
||||
:param path: a :py:class:`py.path.local` - the path to analyze
|
||||
:param _pytest.config.Config config: pytest config object
|
||||
"""
|
||||
|
||||
|
|
@ -199,7 +199,7 @@ def pytest_collect_directory(path, parent):
|
|||
|
||||
Stops at first non-None result, see :ref:`firstresult`
|
||||
|
||||
:param str path: the path to analyze
|
||||
:param path: a :py:class:`py.path.local` - the path to analyze
|
||||
"""
|
||||
|
||||
|
||||
|
|
@ -207,7 +207,7 @@ def pytest_collect_file(path, parent):
|
|||
""" return collection Node or None for the given path. Any new node
|
||||
needs to have the specified ``parent`` as a parent.
|
||||
|
||||
:param str path: the path to collect
|
||||
:param path: a :py:class:`py.path.local` - the path to collect
|
||||
"""
|
||||
|
||||
|
||||
|
|
@ -249,7 +249,10 @@ def pytest_pycollect_makemodule(path, parent):
|
|||
The pytest_collect_file hook needs to be used if you want to
|
||||
create test modules for files that do not match as a test module.
|
||||
|
||||
Stops at first non-None result, see :ref:`firstresult` """
|
||||
Stops at first non-None result, see :ref:`firstresult`
|
||||
|
||||
:param path: a :py:class:`py.path.local` - the path of module to collect
|
||||
"""
|
||||
|
||||
|
||||
@hookspec(firstresult=True)
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ def pytest_addoption(parser):
|
|||
action="store_true",
|
||||
dest="runxfail",
|
||||
default=False,
|
||||
help="run tests even if they are marked xfail",
|
||||
help="report the results of xfail tests as if they were not marked",
|
||||
)
|
||||
|
||||
parser.addini(
|
||||
|
|
|
|||
Loading…
Reference in New Issue