# from chromatic
# on Monday 14 January 2008 16:20:
>> # Don't launch any more tests after ten failed assertions have been
>> seen $ prove --max-fail 10
>
>I can't see how anything else will work in a general sense, at least
> without severe limitations and hack piled upon hack.
Again: Yes.
I suppose I did not use enough words when I said "Can it just be in the
harness?"
As for killing or not, Ovid said:
"Remember that neither of those can really stop the test program from
running. The first could halt *subsequent* test programs from running
and the second could merely discard subsequent test results from a
given TAP stream."
And of course, the '| less' solution mentioned by Sam does roughly that,
though with a less comfortable knob.
So, the skip-on-fail switch should certainly should stop before
displaying the next result (that is just after the diagnostics for the
failure.) Big deal if the process keeps running -- at least we're not
overwhelmed in scrollback.
Though it might not hurt to take a swing with the 'kill -INT' mallet
(certainly worthwhile if you're running an OS where such mallets have
real weight.)
--Eric
--
Speak softly and carry a big carrot.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
