doc: fix broken cross references
This commit is contained in:
parent
4df39e3a1d
commit
e503c9a9f8
|
@ -264,7 +264,7 @@ the cache and nothing will be printed:
|
|||
FAILED test_caching.py::test_function - assert 42 == 23
|
||||
1 failed in 0.12s
|
||||
|
||||
See the :fixture:`config.cache fixture <config.cache>` for more details.
|
||||
See the :fixture:`config.cache fixture <cache>` for more details.
|
||||
|
||||
|
||||
Inspecting Cache content
|
||||
|
|
|
@ -16,8 +16,7 @@ Deprecated Features
|
|||
-------------------
|
||||
|
||||
Below is a complete list of all pytest features which are considered deprecated. Using those features will issue
|
||||
:class:`_pytest.warning_types.PytestWarning` or subclasses, which can be filtered using
|
||||
:ref:`standard warning filters <warnings>`.
|
||||
:class:`PytestWarning` or subclasses, which can be filtered using :ref:`standard warning filters <warnings>`.
|
||||
|
||||
|
||||
The ``pytest_warning_captured`` hook
|
||||
|
@ -376,7 +375,7 @@ Metafunc.addcall
|
|||
|
||||
.. versionremoved:: 4.0
|
||||
|
||||
:meth:`_pytest.python.Metafunc.addcall` was a precursor to the current parametrized mechanism. Users should use
|
||||
``_pytest.python.Metafunc.addcall`` was a precursor to the current parametrized mechanism. Users should use
|
||||
:meth:`_pytest.python.Metafunc.parametrize` instead.
|
||||
|
||||
Example:
|
||||
|
@ -611,7 +610,7 @@ This has been documented as deprecated for years, but only now we are actually e
|
|||
|
||||
.. versionremoved:: 4.0
|
||||
|
||||
As part of a large :ref:`marker-revamp`, :meth:`_pytest.nodes.Node.get_marker` is deprecated. See
|
||||
As part of a large :ref:`marker-revamp`, ``_pytest.nodes.Node.get_marker`` is removed. See
|
||||
:ref:`the documentation <update marker code>` on tips on how to update your code.
|
||||
|
||||
|
||||
|
|
|
@ -592,7 +592,7 @@ will not be executed.
|
|||
Fixtures can introspect the requesting test context
|
||||
-------------------------------------------------------------
|
||||
|
||||
Fixture functions can accept the :py:class:`request <FixtureRequest>` object
|
||||
Fixture functions can accept the :py:class:`request <_pytest.fixtures.FixtureRequest>` object
|
||||
to introspect the "requesting" test function, class or module context.
|
||||
Further extending the previous ``smtp_connection`` fixture example, let's
|
||||
read an optional server URL from the test module which uses our fixture:
|
||||
|
@ -664,7 +664,7 @@ from the module namespace.
|
|||
Using markers to pass data to fixtures
|
||||
-------------------------------------------------------------
|
||||
|
||||
Using the :py:class:`request <FixtureRequest>` object, a fixture can also access
|
||||
Using the :py:class:`request <_pytest.fixtures.FixtureRequest>` object, a fixture can also access
|
||||
markers which are applied to a test function. This can be useful to pass data
|
||||
into a fixture from a test:
|
||||
|
||||
|
|
|
@ -51,7 +51,7 @@ There are several limitations and difficulties with this approach:
|
|||
performs parametrization at the places where the resource
|
||||
is used. Moreover, you need to modify the factory to use an
|
||||
``extrakey`` parameter containing ``request.param`` to the
|
||||
:py:func:`~python.Request.cached_setup` call.
|
||||
``Request.cached_setup`` call.
|
||||
|
||||
3. Multiple parametrized session-scoped resources will be active
|
||||
at the same time, making it hard for them to affect global state
|
||||
|
@ -113,7 +113,7 @@ This new way of parametrizing funcarg factories should in many cases
|
|||
allow to re-use already written factories because effectively
|
||||
``request.param`` was already used when test functions/classes were
|
||||
parametrized via
|
||||
:py:func:`~_pytest.python.Metafunc.parametrize(indirect=True)` calls.
|
||||
:py:func:`metafunc.parametrize(indirect=True) <_pytest.python.Metafunc.parametrize>` calls.
|
||||
|
||||
Of course it's perfectly fine to combine parametrization and scoping:
|
||||
|
||||
|
|
|
@ -112,7 +112,7 @@ More details can be found in the `original PR <https://github.com/pytest-dev/pyt
|
|||
.. note::
|
||||
|
||||
in a future major release of pytest we will introduce class based markers,
|
||||
at which point markers will no longer be limited to instances of :py:class:`Mark`.
|
||||
at which point markers will no longer be limited to instances of :py:class:`~_pytest.mark.Mark`.
|
||||
|
||||
|
||||
cache plugin integrated into the core
|
||||
|
|
|
@ -33,25 +33,25 @@ Consider the following scenarios:
|
|||
|
||||
1. Modifying the behavior of a function or the property of a class for a test e.g.
|
||||
there is an API call or database connection you will not make for a test but you know
|
||||
what the expected output should be. Use :py:meth:`monkeypatch.setattr` to patch the
|
||||
what the expected output should be. Use :py:meth:`monkeypatch.setattr <MonkeyPatch.setattr>` to patch the
|
||||
function or property with your desired testing behavior. This can include your own functions.
|
||||
Use :py:meth:`monkeypatch.delattr` to remove the function or property for the test.
|
||||
Use :py:meth:`monkeypatch.delattr <MonkeyPatch.delattr>` to remove the function or property for the test.
|
||||
|
||||
2. Modifying the values of dictionaries e.g. you have a global configuration that
|
||||
you want to modify for certain test cases. Use :py:meth:`monkeypatch.setitem` to patch the
|
||||
dictionary for the test. :py:meth:`monkeypatch.delitem` can be used to remove items.
|
||||
you want to modify for certain test cases. Use :py:meth:`monkeypatch.setitem <MonkeyPatch.setitem>` to patch the
|
||||
dictionary for the test. :py:meth:`monkeypatch.delitem <MonkeyPatch.delitem>` can be used to remove items.
|
||||
|
||||
3. Modifying environment variables for a test e.g. to test program behavior if an
|
||||
environment variable is missing, or to set multiple values to a known variable.
|
||||
:py:meth:`monkeypatch.setenv` and :py:meth:`monkeypatch.delenv` can be used for
|
||||
:py:meth:`monkeypatch.setenv <MonkeyPatch.setenv>` and :py:meth:`monkeypatch.delenv <MonkeyPatch.delenv>` can be used for
|
||||
these patches.
|
||||
|
||||
4. Use ``monkeypatch.setenv("PATH", value, prepend=os.pathsep)`` to modify ``$PATH``, and
|
||||
:py:meth:`monkeypatch.chdir` to change the context of the current working directory
|
||||
:py:meth:`monkeypatch.chdir <MonkeyPatch.chdir>` to change the context of the current working directory
|
||||
during a test.
|
||||
|
||||
5. Use :py:meth:`monkeypatch.syspath_prepend` to modify ``sys.path`` which will also
|
||||
call :py:meth:`pkg_resources.fixup_namespace_packages` and :py:meth:`importlib.invalidate_caches`.
|
||||
5. Use :py:meth:`monkeypatch.syspath_prepend <MonkeyPatch.syspath_prepend>` to modify ``sys.path`` which will also
|
||||
call ``pkg_resources.fixup_namespace_packages`` and :py:func:`importlib.invalidate_caches`.
|
||||
|
||||
See the `monkeypatch blog post`_ for some introduction material
|
||||
and a discussion of its motivation.
|
||||
|
@ -66,10 +66,10 @@ testing, you do not want your test to depend on the running user. ``monkeypatch`
|
|||
can be used to patch functions dependent on the user to always return a
|
||||
specific value.
|
||||
|
||||
In this example, :py:meth:`monkeypatch.setattr` is used to patch ``Path.home``
|
||||
In this example, :py:meth:`monkeypatch.setattr <MonkeyPatch.setattr>` is used to patch ``Path.home``
|
||||
so that the known testing path ``Path("/abc")`` is always used when the test is run.
|
||||
This removes any dependency on the running user for testing purposes.
|
||||
:py:meth:`monkeypatch.setattr` must be called before the function which will use
|
||||
:py:meth:`monkeypatch.setattr <MonkeyPatch.setattr>` must be called before the function which will use
|
||||
the patched function is called.
|
||||
After the test function finishes the ``Path.home`` modification will be undone.
|
||||
|
||||
|
@ -102,7 +102,7 @@ After the test function finishes the ``Path.home`` modification will be undone.
|
|||
Monkeypatching returned objects: building mock classes
|
||||
------------------------------------------------------
|
||||
|
||||
:py:meth:`monkeypatch.setattr` can be used in conjunction with classes to mock returned
|
||||
:py:meth:`monkeypatch.setattr <MonkeyPatch.setattr>` can be used in conjunction with classes to mock returned
|
||||
objects from functions instead of values.
|
||||
Imagine a simple function to take an API url and return the json response.
|
||||
|
||||
|
@ -330,7 +330,7 @@ This behavior can be moved into ``fixture`` structures and shared across tests:
|
|||
Monkeypatching dictionaries
|
||||
---------------------------
|
||||
|
||||
:py:meth:`monkeypatch.setitem` can be used to safely set the values of dictionaries
|
||||
:py:meth:`monkeypatch.setitem <MonkeyPatch.setitem>` can be used to safely set the values of dictionaries
|
||||
to specific values during tests. Take this simplified connection string example:
|
||||
|
||||
.. code-block:: python
|
||||
|
@ -367,7 +367,7 @@ For testing purposes we can patch the ``DEFAULT_CONFIG`` dictionary to specific
|
|||
result = app.create_connection_string()
|
||||
assert result == expected
|
||||
|
||||
You can use the :py:meth:`monkeypatch.delitem` to remove values.
|
||||
You can use the :py:meth:`monkeypatch.delitem <MonkeyPatch.delitem>` to remove values.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
|
|
|
@ -539,14 +539,11 @@ recwarn
|
|||
.. autofunction:: recwarn()
|
||||
:no-auto-options:
|
||||
|
||||
.. autoclass:: _pytest.recwarn.WarningsRecorder()
|
||||
.. autoclass:: WarningsRecorder()
|
||||
:members:
|
||||
|
||||
Each recorded warning is an instance of :class:`warnings.WarningMessage`.
|
||||
|
||||
.. note::
|
||||
:class:`RecordedWarning` was changed from a plain class to a namedtuple in pytest 3.1
|
||||
|
||||
.. note::
|
||||
``DeprecationWarning`` and ``PendingDeprecationWarning`` are treated
|
||||
differently; see :ref:`ensuring_function_triggers`.
|
||||
|
@ -688,8 +685,8 @@ All runtest related hooks receive a :py:class:`pytest.Item <pytest.Item>` object
|
|||
.. autofunction:: pytest_runtest_makereport
|
||||
|
||||
For deeper understanding you may look at the default implementation of
|
||||
these hooks in :py:mod:`_pytest.runner` and maybe also
|
||||
in :py:mod:`_pytest.pdb` which interacts with :py:mod:`_pytest.capture`
|
||||
these hooks in ``_pytest.runner`` and maybe also
|
||||
in ``_pytest.pdb`` which interacts with ``_pytest.capture``
|
||||
and its input/output capturing in order to immediately drop
|
||||
into interactive debugging when a test failure occurs.
|
||||
|
||||
|
|
|
@ -367,7 +367,7 @@ warnings, or index into it to get a particular recorded warning.
|
|||
|
||||
.. currentmodule:: _pytest.warnings
|
||||
|
||||
Full API: :class:`WarningsRecorder`.
|
||||
Full API: :class:`~_pytest.recwarn.WarningsRecorder`.
|
||||
|
||||
.. _custom_failure_messages:
|
||||
|
||||
|
|
|
@ -111,7 +111,7 @@ class TempdirFactory:
|
|||
_tmppath_factory = attr.ib(type=TempPathFactory)
|
||||
|
||||
def mktemp(self, basename: str, numbered: bool = True) -> py.path.local:
|
||||
"""Same as :meth:`TempPathFactory.mkdir`, but returns a ``py.path.local`` object."""
|
||||
"""Same as :meth:`TempPathFactory.mktemp`, but returns a ``py.path.local`` object."""
|
||||
return py.path.local(self._tmppath_factory.mktemp(basename, numbered).resolve())
|
||||
|
||||
def getbasetemp(self) -> py.path.local:
|
||||
|
|
Loading…
Reference in New Issue