If not test first, then test really soon!

I've spent the last week or so porting the Squiz coding standard sniffs from our old SVN repository to PEAR's PHP_CodeSniffer CVS repository. I'd forgotten just how many there are! For each sniff, I have to write the unit tests as well, which really should have been done back when the sniffs were first written.

For such a small piece of software, the number of tests I have to write is amazing. It doesn't surprise me, but it is getting to me. There is not a lot of "real coding" to be done during this port. Some of the sniffs need a rewrite to bring them in-line with the newer version of PHP_CodeSniffer, but the number of lines of test code far outweigh the number of lines of sniff code, and the job is rapidly losing its appeal.

Compare PHP_CodeSniffer to a large project like MySource Matrix and it's pretty easy to see why the tests need to be written at the same time as the code. Unit testing is not something you can just introduce into a large mature software product (believe me, I've tried) unless you want to spend the next N months writing tests instead of new functionality. Even if you could find the time to do it, you would rapidly lose team members out of sheer boredom.

I'm not into the whole "test first" thing, although I do use it for projects like PHP_CodeSniffer, which is almost too well suited for the concept. Having said that, if you're not going to test first, you'd better test really soon!