I finally took time to read Will Shipley’s impassionate 2005 post about unit testing and why he doesn’t do it. He’s of course exaggerating for effect and the post is best taken in together with BBum’s excellent follow-up where he argues that unit testing made a huge amount of sense for his project, but may be less relevant for software that directly interacts with users.
Unit testing serves to define and enforce the interface that a piece of code presents to the outside world, which makes most sense (and makes a whole lot of sense) when the user of the code is itself a program. Hence: libraries, Frameworks (oh wait, they are also teh suck) and the like. Having a comprehensive set of unit tests gives the folks who have to work with your code confidence in its quality, and gives you liberty to change stuff under the hood as you see fit, with no fear (ok, less fear) of breaking the confidence the other folks have.
Unit tests don’t find bugs. They ensure that there is no unpredictable behavior (bugs) in the bits they test, but they are not as good at finding new bugs that you didn’t know were there. That’s still up to other techniques like exploratory testing that Will likes so much better. Perhaps Unit Testing is incorrectly named, and we should be talking about Unit Verification.
