Test::Harness in Core

[Steve Purkis]

On 8 Jun 2009, at 19:51, David Golden wrote:

> On Mon, Jun 8, 2009 at 12:46 PM, Ovid<publiustemp-tapx at yahoo.com>  
> wrote:
>> What would it take for TH to be split into two distributions?  One  
>> of those would reside in core and only contain core features.  The  
>> other (Test::Harness::Extended?) would be where new features are  
>> developed.
>
> Are you sure this isn't a job for roles?  ;-)  (j/k)
>
> On the serious side, Test::Harness has done a pretty good job of
> breaking up functionality into separate modules -- the problem is that
> it's damn hard to replace any one of those in practice given the way
> testing is called from EU::MM or M::B.  I recently added support for a
> "HARNESS_SUBCLASS" environment variable so that TAP::Harness could
> easily be replaced by TAP::Harness::Archive without re-writing
> someone's build code.
>
> That's a hack, but it's a symptom of the larger problem.  If
> Test::Harness were written to make it easy to swap in components, then
> that could the module that remains core and everything fancy could be
> Test::HarnessX::Foo, etc.

Agreed.

That's one of the problems that's come up on the "Perl's not the only  
TAP source" thread... hopefully we've solved the main case where you  
want to add a new source (like an archive).  That should reduce the  
cases where you'd want or need to sub-class at the level of  
TAP::Harness (or TAP::Parser), which is a step in the right  
direction.  If there are other use cases, we should list them out, and  
find similar ways of dealing with them.  If we need better hooks into  
M::B or EU::MM, then we should list those to.

For example, I still think the App::Prove plugin system needs some  
work (support plugin-defined cmdline params).  But arguably App::Prove  
doesn't need to be in Core (ie: it wouldn't be used directly by build  
scripts), so not something we need to worry about here.

As for adding Test::Harness to Core, I think it makes sense, but only  
after we sort out the plugin / extension system.  Otherwise we'll  
create a swath of backwards-compat pain that we've got to deal with  
for years to come.

+--
   Steve Purkis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.hexten.net/pipermail/tapx-dev/attachments/20090608/54eea943/attachment.htm