Of all of the frustrating debates in software development, bickering over the value of automated testing confuses me the most. I can understand why people who've never tried pair programming seriously have doubts about it. I can even understand why people who know nothing about programming or construction think that designing a building is like designing software.

I don't understand programmers who think automated testing isn't all that useful because tests can be difficult to maintain.

Perl's testing culture had its renaissance when several of us realized that people saw testing as confusing black magic. (No joke; the "copy and paste this header into all of your test files!" generated by h2xs in test.pl used to say "black magic here" before four lines of gobbledegook.)

The nice thing about a renaissance is that you can clear away confusing, magical thinking and replace it with bright, understandable foundations for grander, more elegant, more powerful, and futureful thought.

This occurred on two levels. First, the parallel development of Test::Simple and Test::More made two libraries that were almost trivially easy to understand. Writing good tests requires skill and experience, but writing tests at all requires two minutes of reading and experimenting. The path to mastery begins not with copying and pasting black magic gobbledegook that explicitly warns you off of understanding it but by saying what you mean to say.

Another part of that was good initial design of what would become TAP way back in 1987, as well as other parts of the toolchain, but removing the initial barrier to starting was a huge improvement.

The other foot of the renaissance was Test::Builder. You can start with Test::More and use it productively... but if you're not careful, you'll end up with long, procedural test files with a lot of duplication.

Test::Builder exists solely to remove duplication. It's a foundational library for the abstraction of tests and test structures. You can see this in Testing with Test::Class. You don't necessarily have to write your own testing modules to take advantage of this possibility; the CPAN has hundreds of Test::* modules for your own use.

That's what modern Perl programmers do. We solve problems, then we make the solutions available. We'd never have achieved this for our tests if we hadn't realized the simple, fundamental fact of automated tests: they're just code. All of the good habits you have for managing code apply to managing tests.

That includes choosing the proper libraries and abstractions.