An argument I often hear from TDD critics is that TDD is bad because it doesn’t enforce good architecture.

“What is the benefit of incremental development, and automated tests validating every change, if I’m writing the wrong thing? Or building it in an unsustainable way?”

Well, this is a good point. Automated tests for wortless code is pretty worthless.

But then, if you’re looking to TDD to magically provide a good architecture, you have unrealistic expectations.

“Oh, but TDD advocates are big fans of evolutionary design!”

Ah-ha! Yes. Many TDD advocates are fans of evolutionary design. And many of them talk about the way their design grows from TDD. But let’s be clear. Evolutionary Design is not a side effect of TDD. It’s not a natural occurrence when you practice TDD.

Rather, Evolutionary Design is enhanced, perhaps even enabled, by TDD. And when you become proficient in both, you tend to stop thinking about them as separate practices, although in many ways they really are.

Let me break it down a bit more.

Evolutionary Design is not the idea that we have no idea what our end design or architecture will look like. It’s not “Emerging Design”. Rather, it’s the idea that our design evolves over time. And that we are able to adapt our code to our new concepts gradually as it evolves.

This approach is most effective with the confidence that our changes to design don’t break functionality. In other words, for ED to be effective, we need to know that our refactors are refactors. You don’t need to strictly adhere to TDD to get this assurance. You just need a lot of good automated tests. And writing your tests before (or maybe immediately after) writing the code it tests, is the best way we know to ensure high quality tests that enable confident refactoring and Evolutionary Design.

So TL;DR; TDD doesn’t give you ED for free. But if you’re doing ED, TDD will make it easier.

I had a good chat with J.B. Rainsberger on this topic on my podcast. If you haven’t listened, check it out.