--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> This is easier to do with Test::Builder because custom features meant
> custom
> functions. Custom functions avoid functionality overlap and users
> write code
> specifically for them. Test::Harness and prove have no such luxury.
Right, let's think about this. Test::Harness features tend to impact
an *entire* test suite and that can be a hard problem to solve. What
does it mean if someone says they want a GUI and colored test results?
Those aren't really the same thing and they could very well try to hook
into the same functions. If you can write code which intelligently
decides the *intent* of potentially conflicting plugins, you'll have
code which can pass the Turing test. We've had several false starts on
this and we decided to focus on those things we can really solve and
understand. When people start writing more and more stuff around
Test::Harness, then we might have a better understanding of what the
real world needs are.
Further, many people have many different needs for a test suite.
Test::Builder essentially gets to limit itself to printing "yes" or
"no", over and over again. So far it's been a one-size-fits-all suit.
Sure, you can write your own testing module, but you're still just
printing "yes" or "no". I don't think it's really fair to take the new
Test::Harness to task for not having immediately solved a far more
difficult problem.
Side note: those features I really want control over in Test::Harness
are the plan() and ok() methods. There's no clean way for me to do
that. Just look at the constructor:
my $Test = Test::Builder->new;
sub new {
my($class) = shift;
$Test ||= $class->create;
return $Test;
}
The class name is hard-coded in there. And look at how much the plan()
method does! Sure, it's all logically related to the plan, but if I
want to customize it, I potentially have to duplicate an awful lot of
code (which I had to do with Test::Aggregate).
> How do you do this without balkanizing TAP::Parser into a bazillion
> mutually
> exclusive subclasses? Something like App::ProvePlus is right out,
> it's just shifting the dumping ground.
I suspect we need a minimal subset of traits (Class::Trait::Lite?)
which can be bundled with Test::Harness.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
