Making a source

[Eric Wilhelm]

# from Andy Armstrong
# on Thursday 26 June 2008 04:06:

>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.

>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?

--Eric
-- 
"Matter will be damaged in direct proportion to its value."
--Murphy's Constant
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------