Making a source

[Steve Purkis]

On Jun 26, 2008, at 16:55, Eric Wilhelm wrote:

> # from Andy Armstrong
> # on Thursday 26 June 2008 04:06:
>> I think that before we make more interface changes I'd like to sketch
>> out some use cases. Let's find out what we'd like the interface to
>> look like from an external perspective before adding more layers of
>> abstraction to an already complex interface.
>>
>> 1) Tests run by make test. Everything goes through the legacy
>> Test::Harness wrapper.
>
> Well, no.  At least, we don't need to worry about adding features via
> the legacy wrapper.  Module::Build will use the TAP::Harness interface
> when available (or something) as soon as I get the tuits.

Agreed - if Test::Harness is deprecated, don't do any extra work on it.


>> How do we inject custom code in this case?
>
> Very similarly to how we do it in prove?

>> 2) Tests run by prove. App::Prove supports -M and -P switches to load
>> custom modules but we've never defined what those plugins should do
>> to insinuate themselves into the harness.
>
> Subclass the harness class as TAP::Harness::Plugged and insert all of
> the plugged-in methods into it?  (I think that would be considered a
> role.)  That's just a thought, and has some caveats about SUPER::foo()
> and also how the plugin calls its private methods (because $self is
> foreign at that point.)
>
> Or perhaps plugins are objects in their own right and they simply  
> answer
> something like entry_points() with a hash?
>
> Does the "many things might replace one method/attribute" case still
> need to be addressed?
>
> Aside:  should there be a TAP::Harness::Plugin:: namespace and a
> shorthand "-M ::Foo" form that would search that?

Well, I don't really know how prove's plugin framework works (even if  
it is not well defined :).  Still, it does seem a consistent way of  
naming plugins.

I've been planning on integrating TAP::Formatter::HTML more closely  
with prove so that you can say:

   prove --html=output.html --css_uris=http://foo/my.css

So hopefully I'll have more of a clue after that.


>> 3) Tests run using a custom test runner that instantiates  
>> TAP::Harness
>> or a subclass thereof.

>> 4) Using TAP::Parser or a subclass thereof on its own. No harness in
>> sight.

My brain's fizzling out, sorry.  Will think about & get back.

-Steve