Test-driven development (TDD) has been seen as an aspect of the Extreme Programming (XP) methodology since the rapid growth of XP mind-share in the early 2000s. This view has begun to change as more developers are trying TDD even without a commitment to XP. Here I’ll talk about just a few of the important things you should and should not do when developing with TDD.
DO: Use your test case to capture the design of the software. If you do you WILL uncover design flaws before they are coded into your system. Oh yes, you do have design flaws, you just have yet to discover them.
DONT: Write just this one line of code that is not tested. If you do you violate the testing cycle. The test must fail before it can pass.
DO: Make small changes to tests and code. This minimizes change between test runs. Then if you find a problem it was likely introduced in the small change.
DO: Think about ways that the test you are writing code to should fail but doesn’t. If you find one stop writing code and write the test.
DONT: Write tests for things you do not need to do today. No dead weight! If you do you bloat your tests and your code.
DO: Use configuration management, even if you work by yourself. It will save you time and heartache eventually.
DO: Refactor! This should include removing code you no longer need. No dead weight! Philosophically refactoring is the acceptance that you are better at doing your job now than you were before, or that time and observation have given you more insight to a problem. Which leads to …
DONT: Think you can’t do wrong. If you do TDD is not for you. You will not refactor. You will not write tests for things you know you can do right without them. You will not benefit from the efficiency introduced by practicing TDD. You will not be able to work in a team that uses TDD or XP. In short your intellect no matter how large you believe it to be is no match for the combinatorial explosion of a complex system, and this system WILL eat all of your time.
These are the best practices I have learned from doing TDD. There are likely some other interesting ideas missing here but these stand out to me as being simple guidelines that keep me to the correct philosophy for doing TDD. In fact the last one pretty much sums up the reasoning behind TDD for me. All the best practices of TDD follow from not thinking I am always correct.
Most methodologies are designed to compensate for human fallibility. TDD just happens to have several measures for working around our faults as developers, and all we need to do to benefit from it is follow the simple process outlined for TDD.