--- Steffen Schwigon <[EMAIL PROTECTED]> wrote:
> Then maybe I haven't understood what the standardization of
> diagnostics is about.
>
> I thought it is primarily meant for the *user* of TAP to transport
> its own diagnostics of its own test runs and test results?
>
> I for instance would use it to transport benchmark results inside
> tests.
And that's fine. You can extend it for any use you like. However,
because diagnostics are currently free-form, it's almost impossible to
do anything *programmatic* with them. So, for example, consider sample
output from Test::Differences:
not ok 1 - lang is respected
# Failed test 'lang is respected'
# at lang.t line 23
# +----+-----+----------+
# | Elt|Got |Expected |
# +----+-----+----------+
# * 0|uno |one *
# * 1|dos |two *
# +----+-----+----------+
Well, that seems fine, but imagine that you have test tool which wants
to automatically jump to the file and line number (or auto-navigate you
through a stack trace). We have to *guarantee* that this format never
changes. Ever worked with a test suite where a bunch of tests failed
because someone corrected the spelling in a 'die' message or
localization breaks your hard-coded string matching? By offering a
well-defined syntax, we can alleviate much of this sort of pain. The
above might well translate to this:
---
file: lang.t
line: 23
results:
have:
- uno
- dos
want:
- one
- two
name: lang is respected
display: |
+----+-----+----------+
| Elt|Got |Expected |
+----+-----+----------+
* 0|uno |one *
* 1|dos |two *
+----+-----+----------+
Then all which really needs to be done is to ensure that your
particular TAP consumer knows what to do with it. In fact, it would be
trivial to simply transform that back to the unstructured diagnostics
we are familiar with.
Cheers,
Ovid
--
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/
