Test results currently look something like this:
t/foo.t. ok
t/bar.t. ok
t/baz.t. 23/?
# Failed test at t/baz.t line 9
# Looks like you failed 2 tests out of 23
t/baz.t. Dubious, test ...
Why do we do this instead of ou
On 10 Dec 2007, at 14:17, Ovid wrote:
And we could even add diagnostics for the non-failing tests. This
could be an alternate output, but now instead of external tools having
to try and parse our ad-hoc Test::Harness output, we could have an
alternate machine read-able output that those tools co
--- Andy Armstrong <[EMAIL PROTECTED]> wrote:
> I like it. But I can't think of a use case off the top of my head. So
> are you thinking something like
>
> $ prove --tap
>
> ?
>
> It's actually quite easy to do - just need to plug in a different
> formatter. Plan == number of test files etc.
--- Andy Armstrong <[EMAIL PROTECTED]> wrote:
> I like it. But I can't think of a use case off the top of my head. So
> are you thinking something like
>
> $ prove --tap
Seems Ricardo Signes likes this idea, too:
http://use.perl.org/~Ovid/journal/35076
Cheers,
Ovid
--
Buy the book - http:/
On 10 Dec 2007, at 16:41, Ovid wrote:
It's actually quite easy to do - just need to plug in a different
formatter. Plan == number of test files etc.
Regrettably, this is merely a gut feeling of mine. Think of the
'Result: PASS' we have at the end of our output now. That could go
away. Becaus
On 10 Dec 2007, at 16:49, Ovid wrote:
I like it. But I can't think of a use case off the top of my head. So
are you thinking something like
$ prove --tap
Seems Ricardo Signes likes this idea, too:
http://use.perl.org/~Ovid/journal/35076
Who? :)
Well, let's do it. Blocks and all.
--
Andy
Ovid wrote:
> Test results currently look something like this:
>
> t/foo.t. ok
> t/bar.t. ok
> t/baz.t. 23/?
> # Failed test at t/baz.t line 9
> # Looks like you failed 2 tests out of 23
> t/baz.t. Dubious, test ...
>
>
Test::More's tests of its recursive testing functions (is_deeply() and the
eq_* functions) with threads has had an annoying intermittent failure for a
while. I've never been able to reproduce it because in the past it has only
occurred on machine types I don't have access to. But I noticed a CPAN
Adam Kennedy posed me a stumper on #toolchain tonight. In short, having a
test which checks your signature doesn't appear to be an actual deterrent to
tampering. The man-in-the-middle can just delete the test, or just the
SIGNATURE file since it's not required. So why ship a signature test?
The
