[tapx-dev] Thoughts about Test::Harness 3.0
shlomif at iglu.org.il
Thu Jun 7 16:58:02 BST 2007
On Thursday 07 June 2007, Michael G Schwern wrote:
> Shlomi Fish wrote:
> > As a result breaking compatiblity with it in my fork, was the first thing
> > I did, after converting the procedures to methods one by one. I
> > originally planned to write a compatible class to Test::Harness, but
> > eventually gave up on the idea. From my impression, writing a compatible
> > Test::Harness that will still benefit from the newer tecnologies will be
> > very hard to do and not really worth it.
> > I think that the number of times Test::Harness, Test::Harness::Straps and
> > friends were customised (being a TAP::Consumer) is very small and
> > neglibile compared to the amount of times people just used "make test",
> > "./Build test" or "prove". I personally heard of less than 10 such cases.
> > And I believe these cases can easily be re-adapted for the newer
> > technologies.
> I live in Portland but I spend a lot of time in Pittsburgh. There's work
> and $girl here. Portland has a large and healthy bicycling community with
> many well maintained, interconnected bike lanes following major roads going
> to interesting places. You can bring your bike on public transit, there's
> even special bike lockers at the major stations. Maps of good cycling
> routes in the city are easy to obtain. Many people use bikes to commute to
> work, even the mayor rides his bicycle. Cars tend to be aware of bikes on
> the road and they share it reasonably well. Most bridges have bike lanes
> and sidewalks.
[ Snipped ]
Well maybe there was an impedance mismatch. Perhaps I didn't phrase myself
better or thought about it too much. Or perhaps you were too trigger happy to
prove me wrong. In any case, here is what I have to say:
First of all I don't have any problem with further work on the TAP
consumers/analysers. Hell, that's what I've been doing with Test::Run for a
long time now, and appreciate any other help.
Secondly, my point was not that we shouldn't work on a better, more modular
and more extensible TAP harness, just that trying to do that with
Test::Harness is not such a good idea. I wouldn't recommend anyone to try to
extend, or embed Test::Harness because the code does not give way to this. If
you have something that does that with Test::Harness (probably in evil,
unspeakable ways), that code should be converted to TAP::Parser or whatever.
If you plan on writing something from scratch, don't use Test::Harness for
that. Again, use TAP::Parser or Test::Run or whatever.
Now for the fact that there are few customisations to TAP consumers now, and
what the future may hold. I agree that more customisations can be written and
possibly should be written. However, you all agree that there are very few
customisations against Test::Harness *now* due to its lack of mudolarity and
extensibility. So, we can assume that these customisations and extensions are
not too critical, and that they can be re-implemented above a different TAP
Finally, the number of CGI scripts in the world far exceeds the number of
different implementations of CGI consumers (i.e: web-servers, etc.) and
always will. Thus, so does the number of TAP producing scripts will always be
greater than the number of different TAP consumers and their different
customisations. While there's still a lot of exciting development you can do
in the realm of TAP consumers, it will still remain out of the direct
involvement of Random-J-QA-Hacker, who will just read:
(or its TAP::Parser / TAP::Harness / whatever equivalent)
and happily run it.
 - by we, I mean all the people who work on TAP harnesses and the members
of this list. <sigh />
Shlomi Fish shlomif at iglu.org.il
If it's not in my E-mail it doesn't happen. And if my E-mail is saying
one thing, and everything else says something else - E-mail will conquer.
-- An Israeli Linuxer
More information about the tapx-dev