diff options
| -rw-r--r-- | doc/en/assert.rst | 8 | ||||
| -rw-r--r-- | doc/en/skipping.rst | 4 | ||||
| -rw-r--r-- | doc/en/warnings.rst | 12 | ||||
| -rw-r--r-- | src/_pytest/recwarn.py | 2 |
4 files changed, 13 insertions, 13 deletions
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 <assertraises>`: .. 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: diff --git a/src/_pytest/recwarn.py b/src/_pytest/recwarn.py index 6c04c2e16..4fe365cda 100644 --- a/src/_pytest/recwarn.py +++ b/src/_pytest/recwarn.py @@ -115,7 +115,7 @@ def warns( one for each warning raised. This function can be used as a context manager, or any of the other ways - ``pytest.raises`` can be used:: + :func:`pytest.raises` can be used:: >>> import pytest >>> with pytest.warns(RuntimeWarning): |