Michael G Schwern wrote: > Ovid wrote: >> From: Michael G Schwern <[EMAIL PROTECTED]> >> >>> I will now break your solution. >>> >>> use Test; >>> plan tests => 1; >>> ok 23, 42; >>> >>> PHEAR MY MAD HAX0R SKILLZ! >>> >>> :P >> Hmm, interesting. My parser handled that just fine. > > Yes, that is interesting. How did it capture the diagnostics going to > STDERR? Wasn't that the > whole problem, tests printing to both STDOUT and STDERR? Test.pm does that. > Are you sure it > processed the diagnostics and it didn't just pass straight through to the > terminal and *look* > like it processed it?
Yep, that's exactly what's happening. Here's what happens when you run your tprove example against my code above but piping STDOUT to /dev/null (so you only see STDERR). If fail.t is written with Test::More, thing go as planned. $ cat ~/tmp/fail.t #!/usr/bin/perl -w use Test::More tests => 1; is 23, 42; $ perl examples/tprove ~/tmp/fail.t > /dev/null $ No output. TAPx::Parser has captured it all via the Test::Builder hack and sent it off to STDOUT. Now let's try Test.pm. $ cat ~/tmp/fail.t #!/usr/bin/perl -w use Test; plan tests => 1; ok 23, 42; $ perl examples/tprove ~/tmp/fail.t > /dev/null # Test 1 got: "23" (/Users/schwern/tmp/fail.t at line 6) # Expected: "42" # /Users/schwern/tmp/fail.t line 6 is: ok 23, 42; $ Diagnostic output leaks out to STDERR, just like with Test::Harness. TAPx::Parser knows nothing about Test.pm and doesn't force it to print everything to STDOUT. The hack will only work for Test::Builder based tests. I said this last month when it came up. You could write a hack for Test.pm too, but not everyone uses Test.pm either. You're going to continually be writing hacks for different test implementations.
