It wasn’t so obvious to me when I bought this book (original version), and even in the time of reading. At least all those nifty tests running during Perl modules installation had some meaning to me… Nonetheless, if smarter than me advised to write tests – I made them a part of my workshop.
Sooner the advantage of having testing suite ahead of writing code became obvious. Having some kind of “living specification” gave me a huge performance thrust, mostly because of the instant gratification. But what was even more important, I was able to track down every improvement, which unintentionally broke some other behavior, implemented before.
But lately I discovered another upside, which importancy is even more significant in the world of Open Source. Namely, it is the possibility to discover some bugs in the external code – modules, libraries, whatever. And not only one can discover it, but while reporting one can provide the failing test. Of course one can use this test not only for reporting, but also for trying his brand new patch before submitting it…
There is some witty saying (based on the famous Murphy’s Law), stating that “cool tools works only in others’ gardens”. So while for many people test are not cool, you can treat this lack of coolness as a proof that tests will work for you. And once you have discovered that tests are really cool, you don’t need such proofs anymore.
Docendo discimus 