But the art in TDD is finding the next test which forces the code to move towards the design you want.
I think this difficulty is more or less the driving motivation behind Justin Searls' London-style approach to TDD. Here's a choice quote:
The first test will result in some immediate problem-solving implementation code. The second test will demand some more. The third test will complicate your design further. At no point will the act of TDD per se prompt you to improve the intrinsic design of your implementation by breaking your large unit up into smaller ones.
Preventing your code¡¯s design from growing into a large, sprawling mess is left as an exercise to the developer. This is why many TDD advocates call for a ¡°heavy refactor step¡± after tests pass, because they recognize this workflow requires intervention on the part of the developer to step back and identify any opportunities to simplify the design.
?
Refactoring after each green test is gospel among TDD advocates (¡°red-green-refactor¡±, after all), but in practice most developers often skip it mistakenly, because nothing about the TDD workflow inherently compels people to refactor until they¡¯ve got a mess on their hands.
?
Some teachers deal with this problem by exhorting developers to refactor rigorously with an appeal to virtues like discipline and professionalism. That doesn¡¯t sound like much of a solution to me, however. Rather than question the professionalism of someone who¡¯s already undertaken the huge commitment to practice TDD, I¡¯d rather question whether the design of my tools and practices are encouraging me to do the right thing at each step in my workflow.
?
The full thing is well worth a read:?.
