From afd53ede6f3c950df3bfc9e81afdd45e09ef6d2b Mon Sep 17 00:00:00 2001 From: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com> Date: Thu, 19 Nov 2020 15:44:59 +0100 Subject: Link mentioned functions instead of using literals (#8045) --- doc/en/assert.rst | 8 ++++---- doc/en/skipping.rst | 4 ++-- doc/en/warnings.rst | 12 ++++++------ 3 files changed, 12 insertions(+), 12 deletions(-) (limited to 'doc') diff --git a/doc/en/assert.rst b/doc/en/assert.rst index 7e43b07fd..b83e30e76 100644 --- a/doc/en/assert.rst +++ b/doc/en/assert.rst @@ -74,7 +74,7 @@ Assertions about expected exceptions ------------------------------------------ In order to write assertions about raised exceptions, you can use -``pytest.raises`` as a context manager like this: +:func:`pytest.raises` as a context manager like this: .. code-block:: python @@ -123,7 +123,7 @@ The regexp parameter of the ``match`` method is matched with the ``re.search`` function, so in the above example ``match='123'`` would have worked as well. -There's an alternate form of the ``pytest.raises`` function where you pass +There's an alternate form of the :func:`pytest.raises` function where you pass a function that will be executed with the given ``*args`` and ``**kwargs`` and assert that the given exception is raised: @@ -144,8 +144,8 @@ specific way than just having any exception raised: def test_f(): f() -Using ``pytest.raises`` is likely to be better for cases where you are testing -exceptions your own code is deliberately raising, whereas using +Using :func:`pytest.raises` is likely to be better for cases where you are +testing exceptions your own code is deliberately raising, whereas using ``@pytest.mark.xfail`` with a check function is probably better for something like documenting unfixed bugs (where the test describes what "should" happen) or bugs in dependencies. diff --git a/doc/en/skipping.rst b/doc/en/skipping.rst index c463f3293..282820545 100644 --- a/doc/en/skipping.rst +++ b/doc/en/skipping.rst @@ -259,7 +259,7 @@ These two examples illustrate situations where you don't want to check for a con at the module level, which is when a condition would otherwise be evaluated for marks. This will make ``test_function`` ``XFAIL``. Note that no other code is executed after -the ``pytest.xfail`` call, differently from the marker. That's because it is implemented +the :func:`pytest.xfail` call, differently from the marker. That's because it is implemented internally by raising a known exception. **Reference**: :ref:`pytest.mark.xfail ref` @@ -358,7 +358,7 @@ By specifying on the commandline: pytest --runxfail you can force the running and reporting of an ``xfail`` marked test -as if it weren't marked at all. This also causes ``pytest.xfail`` to produce no effect. +as if it weren't marked at all. This also causes :func:`pytest.xfail` to produce no effect. Examples ~~~~~~~~ diff --git a/doc/en/warnings.rst b/doc/en/warnings.rst index 7232b676d..5bbbcacbe 100644 --- a/doc/en/warnings.rst +++ b/doc/en/warnings.rst @@ -265,7 +265,7 @@ Asserting warnings with the warns function -You can check that code raises a particular warning using ``pytest.warns``, +You can check that code raises a particular warning using func:`pytest.warns`, which works in a similar manner to :ref:`raises `: .. code-block:: python @@ -293,7 +293,7 @@ argument ``match`` to assert that the exception matches a text or regex:: ... Failed: DID NOT WARN. No warnings of type ...UserWarning... was emitted... -You can also call ``pytest.warns`` on a function or code string: +You can also call func:`pytest.warns` on a function or code string: .. code-block:: python @@ -328,10 +328,10 @@ Alternatively, you can examine raised warnings in detail using the Recording warnings ------------------ -You can record raised warnings either using ``pytest.warns`` or with +You can record raised warnings either using func:`pytest.warns` or with the ``recwarn`` fixture. -To record with ``pytest.warns`` without asserting anything about the warnings, +To record with func:`pytest.warns` without asserting anything about the warnings, pass ``None`` as the expected warning type: .. code-block:: python @@ -360,7 +360,7 @@ The ``recwarn`` fixture will record warnings for the whole function: assert w.filename assert w.lineno -Both ``recwarn`` and ``pytest.warns`` return the same interface for recorded +Both ``recwarn`` and func:`pytest.warns` return the same interface for recorded warnings: a WarningsRecorder instance. To view the recorded warnings, you can iterate over this instance, call ``len`` on it to get the number of recorded warnings, or index into it to get a particular recorded warning. @@ -387,7 +387,7 @@ are met. pytest.fail("Expected a warning!") If no warnings are issued when calling ``f``, then ``not record`` will -evaluate to ``True``. You can then call ``pytest.fail`` with a +evaluate to ``True``. You can then call :func:`pytest.fail` with a custom error message. .. _internal-warnings: -- cgit v1.2.3