unittest - assertDoesNotRaise

[viniciusd]

BPO	29747
Nosy	@bitdancer, @viniciusd
PRs	bpo-29747: AddsTestCase.assertDoesNotRaise assertion method #551
Superseder	bpo-14403: unittest module: provide inverse of "assertRaises"

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2017-03-07.14:13:14.172>
created_at = <Date 2017-03-07.12:51:31.989>
labels = ['3.7', 'type-feature', 'library']
title = 'unittest - assertDoesNotRaise'
updated_at = <Date 2017-03-08.12:39:31.352>
user = 'https://github.com/viniciusd'

bugs.python.org fields:

activity = <Date 2017-03-08.12:39:31.352>
actor = 'viniciusd'
assignee = 'none'
closed = True
closed_date = <Date 2017-03-07.14:13:14.172>
closer = 'r.david.murray'
components = ['Library (Lib)']
creation = <Date 2017-03-07.12:51:31.989>
creator = 'viniciusd'
dependencies = []
files = []
hgrepos = []
issue_num = 29747
keywords = []
message_count = 3.0
messages = ['289161', '289164', '289233']
nosy_count = 2.0
nosy_names = ['r.david.murray', 'viniciusd']
pr_nums = ['551']
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '14403'
type = 'enhancement'
url = 'https://bugs.python.org/issue29747'
versions = ['Python 3.7']

[viniciusd]

Unittest provides us some assert methods, yet one is missing: the assertDoesNotRaise context.
When running tests, tests may end up as failures, successes or errors. It's worth noting that errors and failures are conceptually different, and that's the point on having an assertDoesNotRaise context, alike the assertRaises context.
This context would be useful, for example, when using Selenium client, it would be helpful to know if an alert popped, given there is no method to
check if there is an alert, we'd use a code like:

with assertDoesNotRaise(NoAlertPresentException):
    driver.switch_to.alert.text

It is also important to mention that it makes explicit what we are testing. After all, explicit is better than implicit.

[bitdancer]

This has already been discussed and rejected (bpo-14403). In practice the distinction between a failure and an error is not useful, and a comment in the test is IMO clearer than a no-op context manager: you can use a positive sentence instead of the reader having to understand a double negative ("Make sure there is an alert present; this will raise if not.")

The fact that there is no method to check that there is an alert sounds like a missing feature somewhere outside of Python?

Finally, if having this would in your group's opinion make your test code better, you can add it to your own TestCase subclass. But our conclusion was that it doesn't belong in the stdlib.

[viniciusd]

As a last argument:
It is a matter of coherence/consistency with unittest's API, given that
this module does differentiates errors from failures