Why not use python's assert statement in tests, these days?

Question

In Python testing, why would you use assert methods:

self.assertEqual(response.status_code, 200)
self.assertIn('key', my_dict)
self.assertIsNotNone(thing)

As opposed to the direct assertions:

assert response.status_code == 200
assert 'key' in my_dict
assert thing is not None

According to the docs:

These methods are used instead of the assert statement so the test runner can accumulate all test results and produce a report

However this seems to be bogus, a test runner can accumulate results and produce a report regardless. In a related post unutbu has shown that unittest will raise an AssertionError just the same as the assert statement will, and that was over 7 years ago so it's not a shiny new feature either.

With a modern test runner such as pytest, the failure messages generated by the assertion helper methods aren't any more readable (arguably the camelCase style of unittest is less readable). So, why not just use assert statements in your tests? What are the perceived disadvantages and why haven't important projects such as CPython moved away from unittest yet?

Answer 1

The key difference between using assert keyword or dedicated methods is the output report. Note that the statement following assert is always True or False and can't contain any extra information.

assert 3 == 4

will simply show an AssertionError in the report. However,

self.assertTrue(3 == 4)

Gives some extra info: AssertionError: False is not true. Not very helpful, but consider:

self.assertEqual(3, 4)

It's much better as it tells you that AssertionError: 3 != 4. You read the report and you know what kind of assertion it was (equality test) and values involved.

Suppose you have some function, and want to assert value it returns. You can do it in two ways:

# assert statement
assert your_function_to_test() == expected_result

# unittest style
self.assertEqual(your_function_to_test(), expected_result)

In case of error, the first one gives you no information besides the assertion error, the second one tells you what is the type of assertion (equality test) and what values are involved (value returned and expected).

For small projects I never bother with unittest style as it's longer to type, but in big projects you may want to know more about the error.