[Pdx-pm] Test::Builder calling convention

benh ben.hengst at gmail.com
Tue Mar 17 16:44:24 PDT 2009


If we decupple the display then we can essentually template out any
given data to be TAP. That said what would you want this to look like
as data?

my $data = {
 tests => [
  { pass => 0, have => 'foo', want => 'bar', file => 't/foo.t', line => 23 },
  { pass => 0, msg => 'Failed test in t/foo.t at line 23.' }
 ],
 msg => 'I like pie',
};

I know that TAP has some limitations in the formating of #2 and #3 but
is there any reason to keep that limitation in the way that things are
structured?

On Mon, Mar 16, 2009 at 1:42 PM, Michael G Schwern <schwern at pobox.com> wrote:
> David E. Wheeler wrote:
>> On Mar 13, 2009, at 10:24 PM, Michael G Schwern wrote:
>>
>>> Nope.  The result object stores the diagnostic and then the (currently
>>> non-existent) output object decides what to output, where and how.
>>>
>>> A TAP output object, using normal comment diagnostics, would simply not
>>> display the diagnostic at all if the test passed.  So if it passed you
>>> might see:
>>>
>>>    ok 1
>>>
>>> and if it failed
>>>
>>>    not ok 1
>>>    # fail!
>>
>> That would be fine if there was some way to distinguish failure
>> diagnostics from other kinds of diagnostics. Maybe diag() and err()?
>
> diag() on a result object ties the diagnostic to the result.
>
> diag() on the Builder object is just some random diagnostic.
>
> That said, there's really three kinds of diagnostics.
>
> 1) Structured data diagnostics associated with a test.
>
>  not ok 1
>    ---
>    have: foo
>    want: bar
>    file: t/foo.t
>    line: 23
>    ...
>
> 2) Free form diagnostics associated with a test.
>
>  not ok 1
>  # Failed test in t/foo.t at line 23.
>
> 3) Free form diagnostics not associated with any test.
>
>  # I like pie.
>
> #3 can be split further into levels of information, like syslog.  Currently we
> have diag() and note() to distinguish between user visible and invisible
> messages.  Fortunately, I don't have to worry about how this will be
> implemented in TAP to do it in TB2.
>
> #1 is currently a TAP extension.  TAP has no way of distinguishing between #2
> and #3.  Other testing systems may so it's useful to distinguish.
>
> #1 and #2 are both done as methods on the result object.  $ok->diag([ have =>
> ...]); or $ok->diag($message);  It's probably best to split those into two
> methods so there's your diag() and your err().
>
> #3 is called on the Builder object.  $Builder->diag($message) or maybe
> $Builder->err($message).
>
>
> --
> On error resume stupid
> _______________________________________________
> Pdx-pm-list mailing list
> Pdx-pm-list at pm.org
> http://mail.pm.org/mailman/listinfo/pdx-pm-list
>



-- 
benh~

http://three.sentenc.es/


More information about the Pdx-pm-list mailing list