I am a Unit Test Convert

For any project where I’ve been managing more than one or two developers, I’ve always been a proponent of good testing and QA practises, but until fairly recently I wasn’t big on formal unit testing, especially in my one-man projects.

That’s changing, and fast.
While doing some work on PEAR’s PHP_LexerGenerator, I finally had to give in and get up to speed on unit testing. As a project with a few hundred developers, and as one with a reputation for high code quality to defend, a good QA methodology is not an option.

Not only that, but lexers aren’t exactly the easiest thing to test. It’s not easy to look at a stream of a thousand tokens or so and go “yep, that looks good to me”.

So I got up to speed on PHPUnit, one of the more popular unit test frameworks for PHP. This is a good thing because last week I agreed to help with unit testing in Joomla. I was asked to help with this earlier in the year, and not much got done, partially because of my lack of familiarity with unit testing at anything below the Pointy-Haired Boss level.

This past week I’ve been working on a generic access control list manager, having looked at phpGACL and found it lacking, I gritted my teeth and dove once again into the hairiness that is ACL (my first attempt a few years back took a month to produce nothing useful).

It’s my ACL module that has me converted and preaching the Gospel of Unit Test. The revelation came today as I realized a few things:

• Right off the top, the time I saved not figuring out which little informal test script to run manually probably pays back 75% of the time required to write decent tests.
• The normal development process creates a whole swath of regressions that manifest in obscure ways. It’s easy to add to one part of the code wile breaking other parts in ways that don’t show up right away. Unit tests make those issues show up front and centre, right after you introduce the problem. This takes unit testing return on investment from 75% to about 175%.
• Building tests forces you to discover design problems much earlier in the development process. While not exactly “Test First Programming”, this sort of discovery lets you fix major structural issues before the code is written, rather than after. The ROI on that is impossible to measure, but it probably starts at 200% and goes up from there.

So that’s it. From now on I don’t have time to NOT write unit tests.