# 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 ---------------------------------------------------