Test::Harness features

[David Golden]

On Tue, Jun 9, 2009 at 5:14 PM, Steve Purkis<steve at purkis.ca> wrote:
> As for worrying about how this can be used via Test::Harness I'd say:
> if you want this feature, too bad, you've gotta upgrade.  Yes we need
> to worry about backwards compat, but as far as I know Test::Harness
> never supported plugins ;-).  And as it stands, I can kind of see the
> benefit of making back-doors with %ENV vars, but what stands out to me
> is the cost to us: added complexity, more complicated support cases, a
> stickier backwards compat web, and basically time that could be better
> spent.  So my question is: what's wrong with asking people to upgrade?

On reflection, I have a couple proposals for what to do about
Test::Harness.  Essentially, Test::Harness is just a wrapper around
TAP::Harness. The "problem" is that there has been no easy way to use
anything other than TAP::Harness and there's been no way to extensibly
provide arguments to the TAP::Harness constructor.

(1) HARNESS_SUBCLASS -- make it trivial to specify something other
than TAP::Harness. (I've already added this to trunk)

(2) HARNESS_OPTIONS -- parse this like proverc would be .  Refactor
argument processing out of App::Prove and provide a general routine to
convert command line arguments to TAP::Harness arguments.

Both Test::Harness and App::Prove are just wrappers around
TAP::Harness?  Why not harmonize them?  If there are some options that
only apply to prove, then break those out into "core" TAP::Harness
options and extra prove-only options.

Am I oversimplifying the problem?

-- David