in reply to Need advice on test output

Why is it so critical what the output looks like? The point of a TAP parser is to assemble a data structure representing the test run: then you can emit that information in whatever way, in color and animation if you like, or compare it with other test runs. This *particular* output format is a feature of the "make test"/"prove"-like tool, and it's essential to make it readable for *humans* running the tests in interactive mode, but not necessarily some format that's reparsable by another process into abstract data. So tabular format isn't unreasonable, for example.

That said, I deeply encourage you to make the intermediate abstract test result available for any further processing. How you serialize it is not so important. We've used YAML in Pugs, but Test::TAP::Model doesn't really care. Speaking of which, I've not been following your design, have you considered using that model in the first place?

Replies are listed 'Best First'.
Re^2: Need advice on test output
by Ovid (Cardinal) on Jan 05, 2007 at 10:17 UTC

    The biggest problem affecting the venerable Test::Harness is that the parsing, analyzing, and presentation of TAP output has been so tightly coupled that people have found it very hard to do anything "unusual" with it. My primary goal has been to break that coupling so that you can do anything you want. So the TAPx::Harness uses the TAPx::Parser to parse and analyze results and it presents the summary. It's simple enough that you can now use anything else you want to present this information. So yes, the intermediate abstract test results are all available in a very easy to use format. So here's one simplistic way, for example, of just printing failed tests:

    my $parser = TAPx::Parser->new( { source => 't/customers.t' } ); while ( defined ( my $result = $parser->next ) ) { print $result->as_string . "\n" if ! $result->is_ok; }

    Cheers,
    Ovid

    New address of my CGI Course.