On Friday 22 September 2006 08:51, David E. Wheeler wrote:
> I think that if Ovid hacked Test.pm, then he'd have a 99.99%
> solution. Good enough, no?
The authors of affected distributions could also switch to the
Test::Builder-based Test.pm compatibility module, if I could remember its
name.
On Sep 21, 2006, at 17:43, Michael G Schwern wrote:
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
Hi all,
So here's the thought. If we accept that TAPx::Parser might override certain
bits of Test::Builder's behavior, what about the following *completely optional
behavior that you must explicitly request from TAPx::Parser* (borrowing from
earlier suggestions):
use Test::More qw/no_plan
it is obvious that, in the general case, managing multiple streams on
multiple filehandles using existing technologies is a *hard* problem.
it does, however (and thanks for the hint barrie) seem possible to
solve the problem for special cases--those you can control.
On 9/22/06, Barrie Slaymaker <
* Michael G Schwern <[EMAIL PROTECTED]> [2006-09-22 10:50]:
> $ 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 li
* Ovid <[EMAIL PROTECTED]> [2006-09-22 09:25]:
> However, because of a design limitation in TAP and how
> Test::Simple was implemented, we get one tiny *VISUAL* change.
> We don't get different behavior in tests. We get one
> difference in behavior in their presentation. We see if they
> succeed
I concur, disentangling untagged, combined STDERR and STDOUT streams is
very difficult: the source process' output buffering will cause
desynchronization between the two streams and the OS's timeslices my be
long enough that you get a lot of output between polls in the parent
process.
Further
Test-Harness, Test-Legacy, Test and Test-Simple are proving good at beating up
tprove and TAPx::Parser 0.31. I'd suggest running "tprove --lib t/*.t" in each
of them and watch the fur fly. Sometimes there's failures. Often its
displaying diagnostics which should not be displayed.
The good ne
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,
I don't have time to track this down, but I've noticed the following when I run
my Test::Class tests through prove:
shared_cp $ prove prove -l t/test_class_tests.t
prove.prove does not exist
t/test_class_testsTests::::ControlPanel::Remote
Tests::::DB::V
From: Michael G Schwern <[EMAIL PROTECTED]>
>print "1..1\n";
>print "not ok 1\n";
>print STDERR "# Your shit is broke.\n";
>
> How will TAPx::Parser deal with that?
You know, you could skip this entire response and read my last couple of
paragraphs. That will sum it up.
Hmm, let's
11 matches
Mail list logo
