unittest module: provide inverse of "assertRaises"

[gwrtheyrn]

BPO	14403
Nosy	@pitrou, @voidspace

^{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 = 'https://github.com/voidspace'
closed_at = <Date 2012-03-25.13:14:07.257>
created_at = <Date 2012-03-25.11:43:50.970>
labels = ['type-feature', 'library']
title = 'unittest module: provide inverse of "assertRaises"'
updated_at = <Date 2012-03-25.13:14:07.255>
user = 'https://bugs.python.org/gwrtheyrn'

bugs.python.org fields:

activity = <Date 2012-03-25.13:14:07.255>
actor = 'michael.foord'
assignee = 'michael.foord'
closed = True
closed_date = <Date 2012-03-25.13:14:07.257>
closer = 'michael.foord'
components = ['Library (Lib)']
creation = <Date 2012-03-25.11:43:50.970>
creator = 'gwrtheyrn'
dependencies = []
files = []
hgrepos = []
issue_num = 14403
keywords = []
message_count = 5.0
messages = ['156750', '156752', '156753', '156755', '156757']
nosy_count = 4.0
nosy_names = ['pitrou', 'michael.foord', 'tshepang', 'gwrtheyrn']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue14403'
versions = ['Python 3.3']

[gwrtheyrn]

Most assert statements of the unittest module provide both an assert statement as well as its inverse, like "assertIn" and "assertNotIn". There is apparently no such thing for exceptions.

I can do the following:

with self.assertRaises(SomeException):
do_something()

But not:

with self.assertRaisesNot(SomeException):
do_something()

I don't want to simply execute the code and hope that it doesn't raise an exception, because if it does, the test fails with an "error" status instead of a "failed" status.

A possible workaround is the following code:

try:
do_something()
except SomeException:
self.fail()

But that is not that expressive as an assert statement.

A naming alternative would be "assertDoesNotRaise".

In case this enhancement gets accepted, there should also be an inverse of "assertRaisesRegexp".

[pitrou]

I don't want to simply execute the code and hope that it doesn't raise
an exception, because if it does, the test fails with an "error" status
instead of a "failed" status.

So what?

[gwrtheyrn]

> I don't want to simply execute the code and hope that it doesn't raise
> an exception, because if it does, the test fails with an "error" status
> instead of a "failed" status.

So what?

A buggy test is not the same thing as a test that fails because the test result did not meet your assertions.

[pitrou]

>> I don't want to simply execute the code and hope that it doesn't raise
>> an exception, because if it does, the test fails with an "error" status
>> instead of a "failed" status.
>
> So what?

A buggy test is not the same thing as a test that fails because the
test result did not meet your assertions.

That's a completely meaningless difference in my experience. Raising an
exception usually means the tested code is buggy, not the test.
Whoever introduced this distinction probably overengineered it.

[voidspace]

The opposite of calling assertRaises is simply calling the code. A comment as to why you're calling the code is sufficient documentation as to the intent of the test.

In general the difference be a test failure and error is not useful - you *still* have to look at the traceback (failure details) to see *why* the test failed / errored. I'm sure the distinction comes from JUnit that unittest was originally based on (and yes - overengineered for Python).