Ricardo SIGNES wrote:
> * Michael G Schwern <schw...@pobox.com> [2009-03-31T18:22:50]
>>> What if display types could be provided informationally in the TAP stream.
>>> The stream could include:
>>>
>>> want: foo bar
>>> have: foo bar
>>> presentation: Some::Plugin
>>>
>>> With the plugin installed, the presentation layer could fix the output to be
>>> useful. Without it, you still have the data displayed and could presumably
>>> re-display the TAP stream later with the presenter plugin in place.
>> Your annoyance is valid, but you've reversed the presentation responsibility.
>>
>> The test should not be dictating presentation.
>
> It isn't dictating. It's suggesting a useful default.
>
> Until cpan testers are submitting TAP harness, which would allow the author to
> redisplay the TAP, this would lower the prereqs for installing a distribution
> (you don't need a presentation-like test plugin to test the module).
The presence of a presentation keyword doesn't lower the prereqs over not
having it. At best it keeps it flat. By making it a suggestion (which is
fine) it adds a "recommended" dependency on the plugin module.
Even if it is "a useful default" what does "Some::Plugin" mean and to whom?
TAP::Harness? What about some other TAP consumer? The alternative is to come
up with a generic set of display modes understood by TAP parsers which we're
no where near ready for.
The simple way out, which the OP probably didn't realize, is to simply say
"Presentation" which makes it unofficial [1] and then you can do whatever you
want without worrying about the far reaching consequences.
I will confess, what I'm feeling here is that this is going in the direction
of xUnit where the display modes are locked into the testing system the author
has chosen.
>> The whole point of the structured diagnostics is to allow the user of the
>> test
>> to decide how it's to be displayed. You should simply tell your TAP reader
>> how you want diagnostics formatted. For a textual reader you have to do this
>> before the test is run, but imagine a GUI reader where you can use a
>> contextual menu to change the display of a single assertion after the fact.
>
> I understand that -- but we don't have those yet, and even if we did, we're
> not
> getting the real TAP back, yet, from smokers.
Which would be easier: writing a presentation plugin system, writing plugins,
waiting for Test::Builder to support structured diagnostics, adding a
presentation keyword to all applicable tests and getting smokers to install
all the plugins; or changing the smoking modules to send back the TAP using
the existing TAP::Harness::Archive and waiting for the smokers to upgrade
normally?
[1] I know, we broke down over how do designate an official vs unofficial key
in Oslo. Ovid and I talked about it briefly in Birmingham and /^[a-z]/ ==
"official", everything else unofficial is on again at least for draft purposes.
--
7. Not allowed to add "In accordance with the prophesy" to the end of
answers I give to a question an officer asks me.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
