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
--
http://mail.python.org/mailman/listinfo/python-list
