|P is for Practical|
The Joy of Testby Ovid (Cardinal)
|on Apr 11, 2002 at 19:23 UTC||Need Help??|
From time to time, I remind people that they need to write tests for their work. My first real experience writing unit tests was when I uploaded CGI::Safe to the CPAN. This was actually fairly daunting due to the complex nature of some of what I was doing, coupled with the fact that I had never written tests before. Now, due to incessant prodding from chromatic, I've gone XP and have started writing unit tests before writing code.
If you've ever read anything about a new programming language, you know that you can't just read about it, you have to do it. Once you actually start getting hands-on experience, then, and only then, do you start to grok the depths (if any) of whatever you're getting into.
If you've not written tests before, the following small test script won't make much sense to you, but I'll point out the highlights that led to revelations for me.
Now, this is very simple. I only have 11 tests, but they are for a fairly consistent API for my Engine object. Some of my tests are dependant on the internals and I dither on whether or not that's a good thing, but the beauty of this is pretty straightforward: many of the tests handle methods that I haven't yet written. I put stubs in there that merely return some hardcoded data. Thus, I can test my API and when I need to actually write the methods, I don't have to worry about how consistent my API is. I've already figured this out.
By having a clearer idea of my API, I can better know what I need to do and I write cleaner code. A case in point was when I first started on this project in the PTE (pre-testing era), I was very proud of the fact that the core script that drives an entire site was only about 40 lines long. Now, by starting over (I wasn't very far into the project) and doing my tests up front, the problems with my previous API shone like beacons. Now, assuming that very little changes, my core script to drive an entire site can be reduced to four lines of code!
Further, once I find I need to rework the inner magic of my code, I am confident that I can make nice, sweeping changes and still run my tests and know instantly what went wrong. As this is a research project for my work, I've repeatedly been forced to rework things to try new ideas.
Pure bliss :) Tests. Don't leave home without 'em.
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.