homepage

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".

> 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?

>> 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.

> >> 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.

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).