Remove 'message' parameter docs from assert.rst
As per: https://github.com/pytest-dev/pytest/issues/3974#issuecomment-463462732 Also made the 'match' parameter more prominent
This commit is contained in:
parent
c84ae0bb7a
commit
4bc2f96c93
|
@ -88,23 +88,30 @@ and if you need to have access to the actual exception info you may use::
|
||||||
the actual exception raised. The main attributes of interest are
|
the actual exception raised. The main attributes of interest are
|
||||||
``.type``, ``.value`` and ``.traceback``.
|
``.type``, ``.value`` and ``.traceback``.
|
||||||
|
|
||||||
.. versionchanged:: 3.0
|
You can pass a ``match`` keyword parameter to the context-manager to test
|
||||||
|
that a regular expression matches on the string representation of an exception
|
||||||
|
(similar to the ``TestCase.assertRaisesRegexp`` method from ``unittest``)::
|
||||||
|
|
||||||
In the context manager form you may use the keyword argument
|
import pytest
|
||||||
``message`` to specify a custom failure message::
|
|
||||||
|
|
||||||
>>> with raises(ZeroDivisionError, message="Expecting ZeroDivisionError"):
|
def myfunc():
|
||||||
... pass
|
raise ValueError("Exception 123 raised")
|
||||||
... Failed: Expecting ZeroDivisionError
|
|
||||||
|
|
||||||
If you want to write test code that works on Python 2.4 as well,
|
def test_match():
|
||||||
you may also use two other ways to test for an expected exception::
|
with pytest.raises(ValueError, match=r'.* 123 .*'):
|
||||||
|
myfunc()
|
||||||
|
|
||||||
|
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
|
||||||
|
a function that will be executed with the given ``*args`` and ``**kwargs`` and
|
||||||
|
assert that the given exception is raised::
|
||||||
|
|
||||||
pytest.raises(ExpectedException, func, *args, **kwargs)
|
pytest.raises(ExpectedException, func, *args, **kwargs)
|
||||||
|
|
||||||
which will execute the specified function with args and kwargs and
|
The reporter will provide you with helpful output in case of failures such as *no
|
||||||
assert that the given ``ExpectedException`` is raised. The reporter will
|
|
||||||
provide you with helpful output in case of failures such as *no
|
|
||||||
exception* or *wrong exception*.
|
exception* or *wrong exception*.
|
||||||
|
|
||||||
Note that it is also possible to specify a "raises" argument to
|
Note that it is also possible to specify a "raises" argument to
|
||||||
|
@ -121,23 +128,6 @@ exceptions your own code is deliberately raising, whereas using
|
||||||
like documenting unfixed bugs (where the test describes what "should" happen)
|
like documenting unfixed bugs (where the test describes what "should" happen)
|
||||||
or bugs in dependencies.
|
or bugs in dependencies.
|
||||||
|
|
||||||
Also, the context manager form accepts a ``match`` keyword parameter to test
|
|
||||||
that a regular expression matches on the string representation of an exception
|
|
||||||
(like the ``TestCase.assertRaisesRegexp`` method from ``unittest``)::
|
|
||||||
|
|
||||||
import pytest
|
|
||||||
|
|
||||||
def myfunc():
|
|
||||||
raise ValueError("Exception 123 raised")
|
|
||||||
|
|
||||||
def test_match():
|
|
||||||
with pytest.raises(ValueError, match=r'.* 123 .*'):
|
|
||||||
myfunc()
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
.. _`assertwarns`:
|
.. _`assertwarns`:
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue