I often find myself grinding my teeth over TIMTOWTDI. I'm OK with it when the individual solutions are fairly orthogonal and tailored to a certain subset of the problem domain, and thus perhaps better suited to particular scenarios. However, for something as central to the software development process as unit testing, it strikes me as unfortunate to have a hodge podge of different solutions, many of them unofficial.

As a foil, I very much appreciate that Ruby has a single standard Test::Unit module that apparently everyone uses. It comes with the standard distribution, and it seems reasonably complete and well architected. It's sad that Perl does not have something similar. TIMTOWTDI is a double edged sword, the consequence of which is often that people end up speaking very different dialects of the same language, to the point that communication is stifled, or at least stilted.

As a foil, I very much appreciate that Ruby has a single standard Test::Unit module that apparently everyone uses. It comes with the standard distribution, and it seems reasonably complete and well architected. It's sad that Perl does not have something similar.

Perl does :-)

Perl's standard testing framework is Test::Harness, Test::Builder and Test::More. These have all been core (i.e. they come with the standard distribution) since 5.007003, long before Test::Unit was a core part of Ruby.

Indeed, Test::Unit is a fairly recent addition to Ruby, we were all using RubyUnit not too long ago.

Anybody who is writing test suites and not using Test::Builder based modules is (unless they are dealing with a legacy test suite) making a mistake.

IMHO anyway :-)

If you're doing testing work in Perl I strongly recommend that you join the perl-qa mailing list and take a gander at the material on http://qa.perl.org/.

TIMTOWTDI is a double edged sword, the consequence of which is often that people end up speaking very different dialects of the same language, to the point that communication is stifled, or at least stilted.

The bewildering array of testing modules on CPAN is actually less complicated than it looks.

The majority of testing modules on CPAN are built with Test::Builder and work together with the core Test::More. They're not competitors - they're specialists.

Modules like Test::ISBN, Test::Pod::Coverage and Test::Exception are not alternatives to the core testing framework - they're extensions. They just make testing (in this particular instance) ISBN numbers, POD coverage and exceptions easier than with Test::More.

The difference between Ruby and Perl testing frameworks is really down to more people using Perl for testing work over a longer period of time, rather than TIMTOWTDI. One of the few things I miss from Perl in the Ruby world is the excellent specialised testing tools that Perl gives me.

I think it's fair to say that by far the majority of people use either Test::More, something else that produces TAP-compatible output, or one of the many modules you can layer on top of Test::More itself.

TIMTOWTDI does have benefits that make up for the simplicity a single common module might provide, and that includes getting access to newer testing methodologies that are (arguably) better than xUnit in various cases.

For example, take a look at Test::Inline. This lets you write your tests inline in your modules, right next to the code that it tests, and then run these tests in the appropriate order.

Improvements like this may not have been possible were we limited to one specific package.

To summarise, TAP (Test Anything Protocol) is the standard. Test::More is the most common module used to produce TAP, but you are welcome and encouraged to use any of the dozens of other modules to produce TAP, as the situation dictates.

I agree wholeheartedly. I first learned Perl and love the core language but found TIMTOWTDI to be a real curse when weighing up CPAN's dizzying array of options. I think this is why Perl lost so much web development mindshare to PHP. Maybe it would have helped if the Perl community had put together something like Bundle::WebDevelopment without all the MVC madness and any dependence on mod_perl which many ISPs won't touch. I wince when having to write PHP, having learned Perl first, but there's often no alternative and I put this largely down to Perl's TIMTOWTDI philosophy.

I think you might be correct in saying that PHP won so much mindshare in the web dev arena because of Perl's somewhat fragmented consensus on web app frameworks. I wonder what it is about mod_perl that is so different from mod_php from the ISP admin's viewpoint. Is it that you can get deeper into apache and make it unstable, whereas that is harder in PHP?

I wince merely at the thought of learning much about PHP let alone writing my own stuff with it, so you're doing better than I am...