[tapx-dev] Beta and YAML

[Michael G Schwern]

Ovid wrote:
> The TAP::Parser documentation still claims it's ALPHA software.  I
> would love to change that to BETA, so long as we think it's really
> ready for BETA.  Do we anticipate any more interface changes? 
> Obviously we might have changes in the harness API or the parser
> internals, so perhaps that should be separate.  Thoughts?  I know it's
> a tiny thing, but given a recent confusion on London.pm over the ALPHA
> designation of Devel::Cover, I thought it might be nice to switch.
> 
> On the subject of YAML, though we're still talking about how to parse
> the YAML diagnostics, does the TH3 harness even care what those
> diagnostics are so long as they are valid YAML?  I could easily see
> custom harness needing the line number, file name, etc., but TH is
> basically a dumb harness which spits out passed/failed.  We don't need
> anything more than that, do we?

I'd like it if a producer didn't have to output both its own free form
information about a failure (ie. what currently goes to STDERR) and the TAP
diagnostics.  The idea is the TAP consumer reads the diagnostics and displays
the information how it likes.  The TAP producer can still suggest how it
should be displayed, but that part does into the YAML block.

That is given the code:

    use Test::More tests => 1;
    is( 23, 42, "23 is 42, damnit!");

Currently Test::More outputs:

    not ok 1 - 23 is 42 damnit!
    #   Failed test '23 is 42 damnit!'
    #   at foo.t line 2.
    #          got: '23'
    #     expected: '42'

And the user sees all the stuff in the comments, because it goes to STDERR.
It remains the same with the proposal to have a new syntax for free-form
display, except the harness just passes that text on to the user.

But if it were using TAP diagnostics it would be:

    not ok 1 - 23 is 24 damnit!
      ---
      name: 23 is 42 damnit!
      file: foo.t
      line: 2
      actual:   23
      expected: 42
      display: |
        #   Failed test '23 is 42 damnit!'
        #   at foo.t line 2.
        #          got: '23'
        #     expected: '42'
      ...

And the harness would be the thing which reads the diagnostics and decides how
to display it.  The "display" key allows the producer to suggest to the
harness what to display, the harness is free to ignore it.  It also means the
harness doesn't have to figure out how to display everything.

So yes, it would be nice if TH understood what to do with the YAML.