On Tue, Sep 27, 2011 at 4:43 PM, Steven D'Aprano <st...@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) - 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) - 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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
