[Pdx-pm] Test::Builder calling convention

Michael G Schwern schwern at pobox.com
Mon Mar 16 13:42:38 PDT 2009


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


More information about the Pdx-pm-list mailing list