pytest assert Exception

绝地灬酷狼 2021-12-16 05:55 183阅读 0赞

## Asserting with the `assert` statement ##

`pytest` allows you to use the standard python `assert` for verifying expectations and values in Python tests. For example, you can write the following:

# content of test_assert1.py
    def f():
        return 3
    
    def test_function():
        assert f() == 4

to assert that your function returns a certain value. If this assertion fails you will see the return value of the function call:

$ pytest test_assert1.py
    ======= test session starts ========
    platform linux -- Python 3.5.2, pytest-3.0.3, py-1.4.31, pluggy-0.4.0
    rootdir: $REGENDOC_TMPDIR, inifile:
    collected 1 items
    
    test_assert1.py F
    
    ======= FAILURES ========
    _______ test_function ________
    
        def test_function():
    >       assert f() == 4
    E       assert 3 == 4
    E        +  where 3 = f()
    
    test_assert1.py:5: AssertionError
    ======= 1 failed in 0.12 seconds ========

`pytest` has support for showing the values of the most common subexpressions including calls, attributes, comparisons, and binary and unary operators. (See [Demo of Python failure reports with pytest][]). This allows you to use the idiomatic python constructs without boilerplate code while not losing introspection information.

However, if you specify a message with the assertion like this:

assert a % 2 == 0, "value was odd, should be even"

then no assertion introspection takes places at all and the message will be simply shown in the traceback.

See [Advanced assertion introspection][] for more information on assertion introspection.

## Assertions about expected exceptions ##

In order to write assertions about raised exceptions, you can use `pytest.raises` as a context manager like this:

import pytest
    
    def test_zero_division():
        with pytest.raises(ZeroDivisionError):
            1 / 0

and if you need to have access to the actual exception info you may use:

def test_recursion_depth():
        with pytest.raises(RuntimeError) as excinfo:
            def f():
                f()
            f()
        assert 'maximum recursion' in str(excinfo.value)

`excinfo` is a `ExceptionInfo` instance, which is a wrapper around the actual exception raised. The main attributes of interest are `.type`, `.value` and `.traceback`.

Changed in version 3.0.

In the context manager form you may use the keyword argument `message` to specify a custom failure message:

>>> with raises(ZeroDivisionError, message="Expecting ZeroDivisionError"):
    ...    pass
    ... Failed: Expecting ZeroDivisionError

If you want to write test code that works on Python 2.4 as well, you may also use two other ways to test for an expected exception:

pytest.raises(ExpectedException, func, *args, **kwargs)
    pytest.raises(ExpectedException, "func(*args, **kwargs)")

both of which execute the specified function with args and kwargs and asserts 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*.

Note that it is also possible to specify a “raises” argument to `pytest.mark.xfail`, which checks that the test is failing in a more specific way than just having any exception raised:

@pytest.mark.xfail(raises=IndexError)
    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 `@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.

If you want to test that a regular expression matches on the string representation of an exception (like the `TestCase.assertRaisesRegexp` method from `unittest`) you can use the `ExceptionInfo.match` method:

import pytest
    
    def myfunc():
        raise ValueError("Exception 123 raised")
    
    def test_match():
        with pytest.raises(ValueError) as excinfo:
            myfunc()
        excinfo.match(r'.* 123 .*')

The regexp parameter of the `match` method is matched with the `re.search` function. So in the above example `excinfo.match('123')` would have worked as well.

或者：**assert** **excinfo.match(r'.\* 123 .\*') ！= None**

例子:

import re
    import pytest
    
    def check_email_format(email):
        """check that the entered email format is correct"""
        if not re.match(r"(^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$)", email):
            raise Exception("Invalid email format")
        else:
            return "Email format is ok"
    
    def test_email_exception():
        """test that exception is raised for invalid emails"""
        with pytest.raises(Exception) as e:
            assert check_email_format("bademail.com")
        assert str(e.value) == "Invalid email format"

## Assertions about expected warnings ##

New in version 2.8.

You can check that code raises a particular warning using [pytest.warns][].

## Making use of context-sensitive comparisons ##

New in version 2.0.

`pytest` has rich support for providing context-sensitive information when it encounters comparisons. For example:

# content of test_assert2.py
    
    def test_set_comparison():
        set1 = set("1308")
        set2 = set("8035")
        assert set1 == set2

if you run this module:

$ pytest test_assert2.py
    ======= test session starts ========
    platform linux -- Python 3.5.2, pytest-3.0.3, py-1.4.31, pluggy-0.4.0
    rootdir: $REGENDOC_TMPDIR, inifile:
    collected 1 items
    
    test_assert2.py F
    
    ======= FAILURES ========
    _______ test_set_comparison ________
    
        def test_set_comparison():
            set1 = set("1308")
            set2 = set("8035")
    >       assert set1 == set2
    E       assert {'0', '1', '3', '8'} == {'0', '3', '5', '8'}
    E         Extra items in the left set:
    E         '1'
    E         Extra items in the right set:
    E         '5'
    E         Use -v to get the full diff
    
    test_assert2.py:5: AssertionError
    ======= 1 failed in 0.12 seconds ========

Special comparisons are done for a number of cases:

*  comparing long strings: a context diff is shown
 *  comparing long sequences: first failing indices
 *  comparing dicts: different entries

See the [reporting demo][Demo of Python failure reports with pytest] for many more examples.

## Defining your own assertion comparison ##

It is possible to add your own detailed explanations by implementing the `pytest_assertrepr_compare` hook.

`pytest_assertrepr_compare`(*config*, *op*, *left*, *right*)[\[source\]][source]

return explanation for comparisons in failing assert expressions.

Return None for no custom explanation, otherwise return a list of strings. The strings will be joined by newlines but any newlines *in* a string will be escaped. Note that all but the first line will be indented sligthly, the intention is for the first line to be a summary.

As an example consider adding the following hook in a conftest.py which provides an alternative explanation for `Foo` objects:

# content of conftest.py
    from test_foocompare import Foo
    def pytest_assertrepr_compare(op, left, right):
        if isinstance(left, Foo) and isinstance(right, Foo) and op == "==":
            return ['Comparing Foo instances:',
                    '   vals: %s != %s' % (left.val, right.val)]

now, given this test module:

# content of test_foocompare.py
    class Foo:
        def __init__(self, val):
            self.val = val
    
        def __eq__(self, other):
            return self.val == other.val
    
    def test_compare():
        f1 = Foo(1)
        f2 = Foo(2)
        assert f1 == f2

you can run the test module and get the custom output defined in the conftest file:

$ pytest -q test_foocompare.py
    F
    ======= FAILURES ========
    _______ test_compare ________
    
        def test_compare():
            f1 = Foo(1)
            f2 = Foo(2)
    >       assert f1 == f2
    E       assert Comparing Foo instances:
    E            vals: 1 != 2
    
    test_foocompare.py:11: AssertionError
    1 failed in 0.12 seconds

## Advanced assertion introspection ##

New in version 2.1.

Reporting details about a failing assertion is achieved either by rewriting assert statements before they are run or re-evaluating the assert expression and recording the intermediate values. Which technique is used depends on the location of the assert, `pytest`configuration, and Python version being used to run `pytest`.

By default, `pytest` rewrites assert statements in test modules. Rewritten assert statements put introspection information into the assertion failure message. `pytest` only rewrites test modules directly discovered by its test collection process, so asserts in supporting modules which are not themselves test modules will not be rewritten.

Note

`pytest` rewrites test modules on import. It does this by using an import hook to write a new pyc files. Most of the time this works transparently. However, if you are messing with import yourself, the import hook may interfere. If this is the case, simply use `--assert=reinterp` or `--assert=plain`. Additionally, rewriting will fail silently if it cannot write new pycs, i.e. in a read-only filesystem or a zipfile.

If an assert statement has not been rewritten or the Python version is less than 2.6, `pytest`falls back on assert reinterpretation. In assert reinterpretation, `pytest` walks the frame of the function containing the assert statement to discover sub-expression results of the failing assert statement. You can force `pytest` to always use assertion reinterpretation by passing the `--assert=reinterp` option.

Assert reinterpretation has a caveat not present with assert rewriting: If evaluating the assert expression has side effects you may get a warning that the intermediate values could not be determined safely. A common example of this issue is an assertion which reads from a file:

assert f.read() != '...'

If this assertion fails then the re-evaluation will probably succeed! This is because `f.read()`will return an empty string when it is called the second time during the re-evaluation. However, it is easy to rewrite the assertion and avoid any trouble:

content = f.read()
    assert content != '...'

All assert introspection can be turned off by passing `--assert=plain`.

For further information, Benjamin Peterson wrote up [Behind the scenes of pytest’s new assertion rewriting][Behind the scenes of pytest_s new assertion_rewriting].

New in version 2.1: Add assert rewriting as an alternate introspection technique.

Changed in version 2.1: Introduce the `--assert` option. Deprecate `--no-assert` and `--nomagic`.

Changed in version 3.0: Removes the `--no-assert` and\`\`–nomagic\`\` options.

转自：[https://docs.pytest.org/en/3.0.3/assert.html?highlight=re][https_docs.pytest.org_en_3.0.3_assert.html_highlight_re]

[Demo of Python failure reports with pytest]: https://docs.pytest.org/en/3.0.3/example/reportingdemo.html#tbreportdemo
[Advanced assertion introspection]: https://docs.pytest.org/en/3.0.3/assert.html?highlight=re#assert-details
[pytest.warns]: https://docs.pytest.org/en/3.0.3/recwarn.html#warns
[source]: https://docs.pytest.org/en/3.0.3/_modules/_pytest/hookspec.html#pytest_assertrepr_compare
[Behind the scenes of pytest_s new assertion_rewriting]: http://pybites.blogspot.com/2011/07/behind-scenes-of-pytests-new-assertion.html
[https_docs.pytest.org_en_3.0.3_assert.html_highlight_re]: https://docs.pytest.org/en/3.0.3/assert.html?highlight=re