Extending unittests [proposal] [Proof Of Concept]

[Jens Mueller]

David Piepgrass wrote:
> >However, what's truly insane IMHO is continuing to run a unittest
> >block after
> >it's already had a failure in it. Unless you have exceedingly
> >simplistic unit
> >tests, the failures after the first one mean pretty much _nothing_
> >and simply
> >clutter the results.
> 
> I disagree. Not only are my unit tests independent (so of course the
> test runner should keep running tests after one fails) but often I
> do want to keep running after a failure.
> 
> I like the BOOST unit test library's approach, which has two types
> of "assert": BOOST_CHECK and BOOST_REQUIRE. After a BOOST_CHECK
> fails, the test keeps running, but BOOST_REQUIRE throws an exception
> to stop the test. When testing a series of inputs in a loop, it is
> useful (for debugging) to see the complete set of which ones succeed
> and which ones fail. For this feature (continuation) to be really
> useful though, it needs to be able to output context information on
> failure (e.g. "during iteration 13 of input group B").

This leads us to the distinction of exceptions and errors. It is safe to
catch exceptions but less so for errors. At least it is far more
dangerous and less advised to continue execution but should not be
prohibited I think.

Jens