Something strange is going through TDD land these last couple of weeks. First it was Uncle Bob,with a new TDD theory – making tests pass in a certain order, actually helps incremental design, leading to a better solution. This is a very interesting post, and if he’s right, he might have discovered the cornerstone of ALM 2.0.

Following that Mark Seemann’s TDD Apostate questioned the assumption that TDD is a magic bullet for good design. A week later, Michael Feathers posted on the same subject from a different angle: how language and design granularity affect the resulting design of the code.

What do the three posts have in common?

TDD is not what we thought it was.

• Uncle Bob says there is a blind spot in the current TDD process. If we could just identify it, it would help us get to the great design systematically.
• Mark Seemann says TDD is not a good design tool by itself. It could be if you’re a good designer. But by itself, it’s just a process.
• Michael feathers says TDD is affected by the environment, namely your code starting point, and even the language it’s written in.

Let’s not jump to conclusions. TDD has not failed. It has not even changed direction (at least until Uncle Bob or Michael Feathers prove me wrong). But it is the first shift in over 10 years in one of the most uncontested practices in XP or any agile methodology. Apparently, we don’t know everything about it.

TDD does not guarantee a good design. If you know what you’re doing it will probably work. If you know about SOLID, if you suffered from code maintainability in the past, you’d probably get a better design eventually. But it’s up to the driver.

TDD is still THE responsible way to develop software. It’s main value: It makes you think before you code. But it won’t prevent you from messing up if you don’t know what you’re doing. Placed in inexperienced hands, it will blow up in the face. Without knowledge in software design, it’s just a technique that produces tests.

I’m really interested to see where TDD is going next. For the time being, I suggest we go back to the original TDD acronym, though, where D stood for Development. Until we know better, let’s not make promises we can’t keep.

Gil Zilberfeld