http://qs1969.pair.com?node_id=1000793


in reply to Bailing out when testing

See the docs for prove.

There is no documented option to stop on the first faliure, so not directly.

A couple of suggestions:

Also how long do your tests take to run, and how many tests are your putting in each .t file? I think you might be doing stuff wrong if each .t file takes more than a few seconds to run. Perhaps you need to break up your tests into many smaller test files, and simplfy what they do to remove longer running operations.

When I develop tests scripts, I usualy try to limit the number of tests to arround 100 per .t file, so that each individual test file runs quickly. If there are tests that take a significant lenght of time (eg: due to network or database access), I use an environment varable or command line switch to skip them untill all the other tests are working.

You can also speed up testing via prove by running several tests in parallel. On my (4 core) machine, I usualy run something like:

find t -name *.t | xargs prove -j9 -s

find will find all the test file in the test subtree of my source tree and pass them to prove, which will run them in random order, with up to 9 tests running at once. Running multiple tests concurrently is also a good way of finding and removing unexpected dependencies between tests.

Replies are listed 'Best First'.
Re^2: Bailing out when testing
by sedusedan (Monk) on Oct 25, 2012 at 10:29 UTC

    I'm talking about a single test file, so -j is irrelevant here.

    Actually it's not how long the test file runs (which is not more than a few seconds), but the amount of diagnostic output that the failures spew. In my particular case I want just the "head" of the diagnostics.

    Anyway, thanks for the suggestions.

      If you only want to do this occasionally, why not pipe the output to 'head'?

      for(split(" ","tsuJ rehtonA lreP rekcaH")){print reverse . " "}print "\b.\n";

        Because the diagnostic of the first failed test might take many lines.

        Anyway, McDarren's links give the necessary background information about issues in adding the requested feature. Perhaps I'll use Test::Most.