Ovid wrote:
> Schwern: you're specifically copied on this as you maintain
> Test::Simple. If we get this working, how would you feel about a patch
> to Test::Simple that makes this automatically incorporated into new
> test suites which upgrade Test::Simple? The obvious problem is that
> this would create a dependency on TAP::Diagnostics (which I'm hoping
> will have no non-core dependencies and work on Perl back to 5.005.) It
> could also be included with Test::Simple as Test::Diagnostics, if you
> prefer.
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.
> Here's what I currently have, based on thoughts from Adrian Howard and
> Schwern, Andy Armstrong and my own imagination:
>
> A stub module named "TAP::Diagnostics". I currently have three poorly
> named functions.
>
> is_new_tap()
>
> The author of a test module can call this to find out if new-style TAP
> diagnostics are supported. This is done internally by checking the
> TAP_VERSION environment variable. This might get internalized in the
> following two functions (though it shouldn't matter if indented YAML is
> encountered by older TAP parsers. It just means that running tests in
> verbose mode will spit out more info).
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();
> diagnostic( {
> found => $found, # can be stand-alone
> wanted => $wanted, # must always be present with 'found'
> display => $display, # optional human-readable presentation
> extra => $extra, # anything else. Useful for custom harnesses
> meta => 0,
> } );
>
> The 'meta' information defaults to true but can be suppressed.
> Currently this allows the line number and filename to be inserted into
> the TAP.
How does it determine the file and line number? Is it the point where
diagnostic() is called or one call level up? Consider...
# 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".
> meta()
>
> This spits out meta informaton. Currently looks like this:
>
> ---
> 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 it.
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
--
Hating the web since 1994.
