[Python-Dev] unittest missing assertNotRaises
exarkun at twistedmatrix.com
exarkun at twistedmatrix.com
Wed Sep 28 02:36:10 CEST 2011
On 27 Sep, 11:58 pm, ckaynor at zindagigames.com wrote:
>On Tue, Sep 27, 2011 at 4:43 PM, Steven D'Aprano <steve at pearwood.info>
>wrote:
>>But I can't see this being a useful test. As written, exceptions are
>>still treated as errors, except for excClass, which is treated as a
>>test failure. I can't see the use-case for that. assertRaises is
>>useful:
>>
>>"IOError is allowed, but any other exception is a bug."
>>
>>makes perfect sense. assertNotRaises doesn't seem sensible or useful
>>to me:
>>
>>"IOError is a failed test, but any other exception is a bug."
>>
>>What's the point? When would you use that?
>
>I've run across a few cases where this is the correct behavior. The
>most recent one that comes to mind is while testing some code which
>has specific silencing options: specifically, writing a main file and
>a backup file, where failure to write the backup is not an error, but
>failure to write the main is. As such, the test suite should have the
>following tests:
>- Failure to write the main should assert that the code raises the
>failure error. No error is a failure, any other error is an error,
>that error is a success. (it may also check that the backup was
>written)
This is assertRaises, not assertNotRaises.
>- Failure to write the backup should assert that the code does not
>raise the failure error. No error is a success, that error is a
>failure, any other error is a error. (it may also check that the main
>was written)
This is calling the function and asserting something about the result.
>- Both succeeding should assert that the files were actually written,
>and that no error was raised. Any other result is an error.
>
>Now, the difference between a Failure and an Error is more or less a
>mute point, however I would expect an Error to be any unexpected
>result, while a Failure is a predicted (either via forethought or
>prior tests) but incorrect result.
assertNotRaises doesn't make anything possible that isn't possible now.
It probably doesn't even make anything easier - but if it does, it's so
obscure (and I've read and written thousands of tests for all kinds of
libraries over the years) that it doesn't merit a dedicated helper in
the unittest library.
Jean-Paul
More information about the Python-Dev
mailing list