What makes the Driven in TDD ?
I was reading Neal Ford’s excellent articles on the benefits of TDD, part 1 and part 2.
One thing that struck me however is the attempt to limit TDD to test first and how this lead to a somewhat dishonest presentation of the test after approach. In the first of these articles the test after approach is stopped before the refinement phase that is made explicit in the rest of the articles and is well worth reading.
It is unfortunate because the real benefits, in terms of quality, from TDD come from the feedback loop that is created between code and test. It is the iterative refinement of the test and the code that provides the real benefits. It is a chicken and egg thing. Neither comes first, what comes first is an initial design idea based on the problem statement. In Neal Ford’s articles, one of those design ideas is to extract the set of factors whereas the problem does not require it (it requires the sum of factors and in many cases only a partial sum).
Testing before or testing after is an axiomatic decision that provides its own set of benefits. First it emphasises that the developer has to think about the design separately from the code. To a large extend this opens creativity as the design will be less constrained by the existing code. It is an explicit permission to re-factor as needed. The second (maybe the biggest) benefit of testing first is, in my opinion, that it is a clear signal that tests are not considered as a second class deliverable but as a scaffolding and design tool.
So to summarise, TDD is a design method in which tests are a design tool (regression testing is a perk). Test first is a process element that helps initiate and sustain TDD.
