Ovid wrote:
Test::Harness used to be very limited. We couldn't do a lot with it,
but when we started testing, most of us didn't do a lot with it. As we
understood more about testing, we understood better many things we
wanted. As a result, Schwern posted a great plan for rewriting
Test::Harness. It worked and people are taking advantage of this.
Now we're starting to see more and more limitations with Test::Builder.
I don't want this to come across as bashing chromatic or Schwern, the
two people who've done most of the great work in writing this and
related code. They produced a great solution and now that we've had a
chance to use it for a while, we have a better idea of what else we
could use. Of course, this is what most of programming is like.
Part of this is driven by the new Test::Harness and part of it is
driven by people's real-world needs. I toss the following out not
because I think everyone will agree with it, but because I think it's a
good starting point. Maybe someone can create TAP::Builder?
* Make it subclassable.
* Allowed deferred plans.
* Allow for TAP upgrades (YAMLish, YAMLish, YAMLish!).
* "On Fail" callbacks? (I realize lots of people will squawk here)
The irony being that if you have N different backends then you can no longer
guarantee any common behavior between the two which means all the
Test::Builder hackery proposed here to add common functionality to all test
modules gets harder, not easier. On the flip side, some of it becomes possible.
There's the more important question of what *must* remain in common so that
modules written with either system can still work together in the same test
process. That being the plan, the test counter and any end-of-test behaviors
have to be coordinated which means at minimum they need an object in common to
register whether there's already a plan and what it is, what the current test
# is and so on.
And then there's what optionally should be coordinated. This is stuff like
what filehandles to output to, historical test data (am I passing?), are we
skipping or todo'ing, are we using test numbers and so on. Global behaviors.
--
If at first you don't succeed--you fail.
-- "Portal" demo
