I’ve been doing Test-Driven Development (TDD) for more than a year now. It’s no silver bullet, but it has helped me catch plenty of mistakes that might otherwise have slipped through to our final product.
TDD, for those of you not familiar with it, is a three step process. When you realize that you’d like your program to do something different that what it already does, you:
- write a test case that would pass if the change was implemented (it will fail intially because it hasn’t yet been implemented)
- implement the change so that the test case passes
- clean up your code
It didn’t take me long to notice that whenever I wanted to make a change, I ended up describing that change in two different places: once in the unit test and once in the production code. It used to bother me that I was doing twice the work that I had been before starting with TDD.
It finally dawned on me that the duplication is the primary benefit of TDD. TDD is the double entry accounting of programming. Whenever you’d like to change your program, you enter the change in two sets of books: test cases, and production code. The duplication is what allows you to detect your errors.
Ken Dyck 