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").
