unittest: assertRaises() with an instance instead of a type

[Ulrich Eckhardt]

Am 28.03.2012 20:07, schrieb Steven D'Aprano:
> First off, that is not Python code. "catch Exception" gives a syntax
> error.

Old C++ habits... :|


> Secondly, that is not the right way to do this unit test. You are testing
> two distinct things, so you should write it as two separate tests:
[..code..]
> If foo does *not* raise an exception, the unittest framework will handle
> the failure for you. If it raises a different exception, the framework
> will also handle that too.
>
> Then write a second test to check the exception code:
[...]
> Again, let the framework handle any unexpected cases.

Sorry, you got it wrong, it should be three tests:
1. Make sure foo() raises an exception.
2. Make sure foo() raises the right exception.
3. Make sure the errorcode in the exception is right.

Or maybe you should in between verify that the exception raised actually 
contains an errorcode? And that the errorcode can be equality-compared 
to the expected value? :>

Sorry, I disagree that these steps should be separated. It would blow up 
the code required for testing, increasing maintenance burdens. Which 
leads back to a solution that uses a utility function, like the one you 
suggested or the one I was looking for initially.


> (By the way, I have to question the design of an exception with error
> codes. That seems pretty poor design to me. Normally the exception *type*
> acts as equivalent to an error code.)

True. Normally. I'd adapting to a legacy system though, similar to 
OSError, and that system simply emits error codes which the easiest way 
to handle is by wrapping them.


Cheers!

Uli