On Fri, Jul 08, 2005 at 15:15:55 +0000, Mark Stosberg wrote: > Thanks to help from a number of people here, I now have a better > understanding of how Test::TAP::HTMLMatrix is used. > > I would like to see it integrated with 'prove', and have looked into > what this would take. Here's what I think needs to happen: > > - Have Test::Harness::Straps be declared 'stable enough' for general > use.
Test::TAP::Model would benefit a LOT from a more hookable straps. I think the best way to do this is make T::H::S a sax event generator thing. Objects like Test::TAP::Model, or the real time progress printing code can subscribe to events, and get notifications as they happen. Each flag to 'prove' for an output mode will just instantiate a default object of a class, and subscribe it to the strap. The object will also have a hook on exit. Options are placed in a global hash, or queried from a 'process' object, so that objects specific to an output is available. Module::Pluggable can be used to 'discover' output modes, and each output mode can also announce it's options so the usage screen can contain them. > - Fix the possible "either/or" problem. From what I can tell, > right now you can't get the usual output and the HTML output > at the same time (maybe I'm wrong here?). This might be done > by adding an as_text() method to Test::TAP::Model or a related > module. This is solved by the previous one. > - Use Test::TAP::HTMLMatrix to run the tests, which would now > support the inherited text output option, as well as HTML option. This should be there only for backwards compatiblity... Since the outputters will be delegates of the stream parser, and the stream parser is just told where to get the streams (by running scripts). > If we want to add a third output option besides as HTML, the internals > would need to be redesigned, perhaps to a "plugin" or "mixin" style > architecture. No, that's silliness ;-) I think actually now is the time, since T::S's interface is nonexistent. > Another route to go might be to publish some of these things as filters: > > prove | tee tap2html ./output_dir/ > prove | tee tap2xml >output.xml > > I haven't through how this would work in the face of having 2 streams > that might have meaningful data on them and aren't synchronized (STDOUT > and STDERR). STDERR should have data only for the user, at least in my experience. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me does a karate-chop-flip: neeyah!!!!!!!!!!!!!!
pgpaFpIBqVlGB.pgp
Description: PGP signature
