--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> As Test::More cannot have any dependencies, I'd rather incorporate
> TAP diagnostic functionality directly into Test::Builder. Besides,
> spitting out some YAML isn't hard.
It turns out to be a fair bit harder than it appears to be on the
surface. For example:
my $data = 3;
my $data = "3";
One is string. One is numeric. As it turns out, it's not easy to find
a pure perl, core method of doing this but it's really important to get
this right. The only thing I could think of was to steal some code
from Ingy's Pointer.pm module. That uses unpack with a 'P' template.
Ugh! Is there another way of doing this? I know Andy Armstrong was
also looking into this, but I'm not sure if he's come up with anything
yet. (A bit of XS makes this simple, but we can't rely on people
having a compiler).
Also, if this gets integrated with Test::Builder, where does the YAML
writer go? I'd hate for yet another YAML writer module to be out
there.
> is_new_tap() sounds more like its testing a TAP stream, not the TAP
> harness.
>
> "new", like "fast" or "lite", is one of those subjective,
> context-sensitive
> adjectives that make for a bad routine name.
>
> How about something more direct: harness_supports_tap_diagnostics();
I thought about something more verbose, but I confess that I like to
avoid longer function names. They irritate people. Still, maybe it's
worth it in this case.
> # diagnostic() should report where test() was called
> sub test {
> my $test = shift;
> print "not " unless $test;
> print "ok 1\n";
> diagnostic( { ... } );
> }
>
> But then there's the problem of how far up the call stack to go?
>
> # diagnostic() should report where get_ok() was called
> sub get_ok {
> my $thing = shift;
> test(get($thing));
> }
>
> You're pretty much reimplementing Test::Builder's "level".
I was aware of that. I was trying to gloss over it for the time being,
even though I know this feature is critical. Your solution of
integrating this into Test::Builder makes this easier.
> > ---
> > executable: perl
> > inc:
> > - lib
> > - t/lib
> > - /System/Library/Perl/5.8.6/darwin-thread-multi-2level
> > - /System/Library/Perl/5.8.6
> > - /Library/Perl/5.8.6/darwin-thread-multi-2level
> > - /Library/Perl/5.8.6
> > - /Library/Perl
> > - /Network/Library/Perl/5.8.6/darwin-thread-multi-2level
> > - /Network/Library/Perl/5.8.6
> > - /Network/Library/Perl
> > -
> /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level
> > - /System/Library/Perl/Extras/5.8.6
> > - /Library/Perl/5.8.1
> > - .
> > os: darwin
> > perl: 5.008006
> > tap_version: 13
> > ...
> >
> > Some of that is Perl-specific and therefore is wrong. However, it
> can
> > be very useful for debugging information.
>
> It's a module for TAP producers so it can go ahead and produce Perl
> specific stuff. Non-perl TAP readers will simply ignore
Actually, I think it would be better if there were a 'perl' key which
keeps perl-specific information grouped together. What if more than
one programming language uses 'inc' and they're running a
multi-language test suite? They might not realize which 'inc' they
need or they might need to test both the language and the 'inc' and
this is a further source of bugs which could propagate. Just add
language-specific stuff to a language-specific key.
> A timestamp would be helpful. The ISO 8601 is easy to machine parse
> but a little hard on humans.
>
> timestamp: 2007-09-01T07:09:54-0700
>
> RFC 3339 is a little easier to read. I'm inclined towards this.
>
> timestamp: 2007-09-01 07:09:54-0700
>
> RFC 2882 format is easier on humans but harder to parse and sort.
>
> timestamp: Mon, 01 Sep 2007 07:09:54 -0700
Agreed. However, I don't know enough about the impact of having that
'T' there and not. I'd prefer one of the first two options rather than
the third.
Cheers,
Ovi
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
