classification
Title: unittest - assertDoesNotRaise
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.7
process
Status: closed Resolution: duplicate
Dependencies: Superseder: unittest module: provide inverse of "assertRaises"
View: 14403
Assigned To: Nosy List: r.david.murray, viniciusd
Priority: normal Keywords:

Created on 2017-03-07 12:51 by viniciusd, last changed 2017-03-08 12:39 by viniciusd. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 551 closed viniciusd, 2017-03-07 15:47
Messages (3)
msg289161 - (view) Author: Vinícius Dantas (viniciusd) * Date: 2017-03-07 12:51
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.
msg289164 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-03-07 14:13
This has already been discussed and rejected (issue 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.
msg289233 - (view) Author: Vinícius Dantas (viniciusd) * Date: 2017-03-08 12:39
As a last argument:
It is a matter of coherence/consistency with unittest's API, given that
this module does differentiates errors from failures
History
Date User Action Args
2017-03-08 12:39:31viniciusdsetmessages: + msg289233
2017-03-07 15:47:18viniciusdsetpull_requests: + pull_request453
2017-03-07 14:13:14r.david.murraysetstatus: open -> closed

superseder: unittest module: provide inverse of "assertRaises"

nosy: + r.david.murray
messages: + msg289164
resolution: duplicate
stage: resolved
2017-03-07 12:51:31viniciusdcreate