RetroSearch Browse

Wed Sep 28 02:36:10 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-September/113720.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-September/113720.html below:

[Python-Dev] unittest missing assertNotRaises