doc: fix broken cross references

This commit is contained in:
Ran Benita 2020-09-06 11:52:30 +03:00
parent 4df39e3a1d
commit e503c9a9f8
9 changed files with 27 additions and 31 deletions

View File

@ -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

View File

@ -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.

View File

@ -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:

View File

@ -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:

View File

@ -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

View File

@ -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

View File

@ -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.

View File

@ -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:

View File

@ -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: