TDD is the red/green/refactor process. Write the test, watch it fail. Go write the bare minimum of code possible to make it pass. Refactor the code, and refactor the tests. Repeat.
This process lends itself to what people call "emergent design." This is the concept that you don't stress out trying to devise some all encompassing design before you begin coding. You sit down, you write tests, and you let the design emerge from the process. The reasoning here is that you'll end up with the simplest possible design that does exactly what you need and nothing more.
That point hits home very strongly for me because of my experience with both applications and code that have been over designed and end up causing all sorts of long term problems. So the call for simplicity is one I am very eager to answer.
BUT. Clearly you can't just close your eyes and code away and assume it will all work out. There is an interesting tight rope walk happening here. As you are coding you have to be constantly evaluating the design and refactoring to represent the solution in the simplest possible way. But what TDD is really trying to get you to do is not think too much about what is coming next and instead pass the current test as though there wasn't going to be a next test.
It's that "ignoring" the future part that I really struggle with. The knee jerk negative reaction is that this will cost you time because you're constantly re-doing work. There are times when this is probably true, but in general the tests lead you through the solution incrementally, affirming you're on the right track each step of the way. And when you suddenly discover something that causes you to back track, you've got all the tests ready to back you up.
But there are a few things that I don't think this technique is good for. One is "compact" algorithms, the other is large systems. We'll take them one at a time. I was recently practicing the Karate Chop Kata which is a binary search. My testing process went like this:
- When array is null or empty it should return negative one
- When array has one item
- it should return zero if item matches
- it should return negative one if item does not match
- When array has two items
- it should return zero if first item matches
- it should return one if second item matches
- it should return negative one if nothing matches
- When array has three items
Numbers 1-3 were all implemented in the straight forward way you would expect. But when I get to #4, now I have to actually write the binary search algorithm. So now I have to decide if I'm going to write it with a loop, with recursion, with some form of "slices", etc. I also have to figure out what the terminating conditions are and verify that my indexes and increments are all correct. In other words I have to do all the work after writing that one test.
And worse, these tests are stupid. What am I going to do, write a test for every array length and every matching index? I re-factored the tests later to be a bit more generic and more specific to the edge cases of the algorithm in question. If you'd like to see what I ended up with you can checkout the code on bitbucket.
In general, writing your tests with knowledge of the implementation you're writing is bad, bad, bad. Like @mletterle reminded me of on twitter, tests should test the behavior of the code, not the implementation of the code. Bob Martin just recently wrote a post that made the same kind of argument in regards to Mocks.
Now don't get me wrong. The tests are still valuable in this example, they're just not as useful in an "emergent design" kind of way.
Moving on, the second thing that the emergent design mindset isn't very good for is complex system design. Systems that are complicated enough to warrant DDD (Domain Driven Design). In this case you really want to step back and take a big picture view and do a real Domain Model. The emergent design approach may lead to a design with fewer objects or something, but this may not be a good thing if you're interested in a design that excels at communication.
With these systems you'd do your Domain Driven Design, then drop into your TDD and allow it to "emergently" design the actual implementation code of your model. You're kind of getting the best of both worlds this way. But its important to recognize that TDD is still an important part of this, even though you didn't let it guide the ENTIRE design.
So TDD and emergent design might not be the answer in all circumstances. But I still think that you'll find a strong place for it in even these circumstances.
Anybody in the blogosphere strongly disagree with this? Or perhaps, dare I ask, agree?