Test Driven Development…
I think it’s always good to cite a source who’s credibility far outreaches your own, I’ve seen many examples of test driven development, implored teams to adopt test driven development, and unit testing in general, and I appreciate how difficult it is for developers to make the change. Developers are after all creatures of habit.
Anyway, I just came across this note within the Subversion development site, dating back to 2001, this is as good a call-to-arms of TDD as I’ve seen, but I think it’s always a good idea to post as many of these as possible…
Many of us implementing the filesystem interface have now gotten into the habit of writing the test cases (see fs-test.c) before writing the actual code. It’s really helping us out a lot — for one thing, it forces one to define the task precisely in advance, and also it speedily reveals the bugs in one’s first try (and second, and third…).
I’d like to recommend this practice to everyone. If you’re implementing an interface, or adding an entirely new feature, or even just fixing a bug, a test for it is a good idea. And if you’re going to write the test anyway, you might as well write it first.
Yoshiki Hayashi’s been sending test cases with all his patches lately, which is what inspired me to write this mail to encourage everyone to do the same. Having those test cases makes patches easier to examine, because they show the patch’s purpose very clearly. It’s like having a second log message, one whose accuracy is verified at run-time.
That said, I don’t think we want a rigid policy about this, at least not yet. If you encounter a bug somewhere in the code, but you only have time to write a patch with no test case, that’s okay — having the patch is still useful; someone else can write the test case.
As Subversion gets more complex, though, the automated test suite gets more crucial, so let’s all get in the habit of using it early.