in reply to Re: Intercepting TAP output
in thread Intercepting TAP output

It would appear to me that a poor initial choice has been made. Test::More would seem ill suited to being the framework for what seems like a network monitoring app. Can you explain the rationale for using Test::More?

It wasn't my choice, but it has a certain elegance. At the point where the customer said that they wanted different output it lost some of that elegance.

TAP::Parser totally looks like the way to go. Thanks!

Peter Scott
Perl Medic

Replies are listed 'Best First'.
Re^3: Intercepting TAP output
by peters (Sexton) on May 09, 2008 at 00:47 UTC
    I have boiled it down to this demo. TAP::Harness looks like the best driver and it has a callback that lets me get at the parser before it would otherwise be used. Silencing the harness means that it never gets to find out that its parsers have been drained.
    use TAP::Harness; my $harness = TAP::Harness->new( { verbosity => -3, merge => 1 } ); my @tests = glob "t/*.t"; $harness->callback( made_parser => \&hijack_parser ); $harness->runtests( @tests ); sub hijack_parser { my ($parser, $test_ref) = @_; while ( my $result = $parser->next ) { $result->is_test or next; $result->is_actual_ok and next; (my $description = $result->description) =~ s/- //; print "I seem to have failed $description in $test_ref->[1]\n"; } }
    Peter Scott
    Perl Medic