Reading some of the software development weblogs lately, it seems like the anti-unit testing backlash has begun. It wasn’t too long ago that people were talking about becoming “test infected” and that Test Driven Development became an important buzzword, the idea being that you would write automated tests to verify that your code worked before writing the code itself, and then making sure that your code complies with those tests throughout the development cycle.

I was a bit late jumping on the bandwagon and becoming test infected, but as soon as I really leapt into it, the value became apparent to me immediately. Indeed, one thing that has been confirmed repeatedly lately is that all of the most embarrassing bugs I’ve had to deal with have been direct products of having poor test coverage for a feature. Had I written all of the unit tests I needed to, I would have caught those bugs and not had to deal with customers contending with them. And the thing is, in every one of those cases, it’s not like I couldn’t foresee needing to write the unit tests I miss. Rather it was that cycles are short and there are too many things to do, and so testing suffers. Anyway, unit testing may be a fad to a certain extent, but it’s a fad that I won’t be leaving behind anytime soon.

There’s no worse feeling than getting burned by a bug and knowing that a bit of extra work on the testing side could have saved you.