Making a source

[Andy Armstrong]

On 25 Jun 2008, at 23:59, Steve Purkis wrote:
> Also, (slightly OT) I was thinking of going OTT and introducing a
> SourceFactory.  This is so you could have Source::Perl,
> Source::Python, Source::PHP, Source::YerMom, etc.  The current source
> could move to Source::Shell (or ::Command).  I don't know how silly
> that is, it's 7 to midnight after all, but the idea was to make it
> really easy to extend sources.

> Finally, (more OnT) I had the pleasure of realizing today that
> there's no easy way to tell TAP::Harness about all this nifty
> subclassing mumbo jumbo.  You have to get stuck in, and create your
> own subclass of T::H if you want a custom Perl source.  That should
> probably change too.


Is subclassing TAP::Harness more difficult than subclassing a factory?  
In code that we have at work I'm currently providing a custom source  
by subclassing TAP::Harness and overriding _get_parser_args.

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.

The four main ways of using T::H are:

1) Tests run by make test. Everything goes through the legacy  
Test::Harness wrapper. How do we inject custom code in this case?

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.

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.

What should each of those cases look like? What can't be achieved now?

-- 
Andy Armstrong, Hexten