Unit testing: A good habit, lost

When I was a Perl programmer, I was a strong believer in testing. I wrote tests before I wrote functions. I wrote tests before I fixed bugs. I ran the test suite every time before I committed changes to svn. I ran tests after I ran svn update.

When I became a PHP programmer, I quickly slipped out of the habit. There were two reasons for this.

First, my style of programming changed pretty drastically, with the move to being completely web-centric, and web front-end code is just harder to test.

Two, at that time, the available tools for unit testing were immature. Or, at least, so I believed, coming from the Perl world where testing is not considered optional, and is integrated into every aspect of the process, from design all the way up to ridiculing stuff that’s submitted to CPAN without adequate tests.

Now that I’ve been doing PHP programming for going on 5 years, I desperately want to get back into a testing mindset, but find that there’s an awful lot of inertia around not testing. If your code doesn’t have a test suite, it’s difficult to make that first leap to build one. And it’s also hard to convince management that it’s worthwhile spending time making a test suite when you’re behind deadlines.

And, since there’s not One True Way in PHP, like there is in Perl, you waste a lot of time and energy trying to find the right testing methodology. The PHP community could do themselves, and the rest of the world, a great service, by agreeing on one testing methodology, and then evangelizing it. Here’s another case where the quest for the best has woefully injured everyone, and led to a situation where people simply don’t test.

Now, I’m sure that the core PHP folks will disagree with me. Actually, I kind of hope that they will. Please disagree with me? Tell me that there is One True Way, and also that you do run the test suite every time you change a line of code. I greatly regret getting out of that habit.