classification
Title: unittest module: provide inverse of "assertRaises"
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: michael.foord Nosy List: gwrtheyrn, michael.foord, pitrou, tshepang
Priority: normal Keywords:

Created on 2012-03-25 11:43 by gwrtheyrn, last changed 2012-03-25 13:14 by michael.foord. This issue is now closed.

Messages (5)
msg156750 - (view) Author: Danilo Bargen (gwrtheyrn) Date: 2012-03-25 11:43
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".
msg156752 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-03-25 12:03
> 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?
msg156753 - (view) Author: Danilo Bargen (gwrtheyrn) Date: 2012-03-25 12:05
>> 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.
msg156755 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-03-25 12:14
> >> 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.
msg156757 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2012-03-25 13:14
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).
History
Date User Action Args
2017-03-07 14:13:14r.david.murraylinkissue29747 superseder
2012-03-25 13:14:07michael.foordsetstatus: open -> closed
assignee: michael.foord
resolution: wont fix
messages: + msg156757
2012-03-25 12:14:38pitrousetmessages: + msg156755
2012-03-25 12:05:49gwrtheyrnsetmessages: + msg156753
2012-03-25 12:03:26pitrousetversions: + Python 3.3, - Python 2.7
nosy: + michael.foord, pitrou

messages: + msg156752

components: + Library (Lib), - Tests
2012-03-25 11:48:51tshepangsetnosy: + tshepang
2012-03-25 11:43:50gwrtheyrncreate