There's two parts to TDD: what it does for you when you are writing a new piece of code, or what it does when you come back to it. IMHO, the advantages when yo

There's two parts to TDD: what it does for you when you are writing a new piece of code, or what it does when you come back to it. IMHO, the advantages when you are writing new code are vastly overstated. A former employer mandated TDD, and I did my best to follow their practices. It doesn't lead me to better modularization, more maintainable code, or really, any less bugs. However, going back to code that actually has a real test suite around it is invaluable. It's not really because the tests prevent you from breaking the code: More often than not, it's the test that needs fixing. The value comes from the tests behaving as living documentation. It lets me see why someone, at some point, wanted the code there. Then I can evaluate if the reasons are still valid, and wonder if the old requirements still make sense, or whether my updated requirements are going to be an issue, because someone forgot some byzantine case that the tests just reminded us of. Now, the question is whether we are better off getting here through TDD and a quest for full test coverage, or something higher level, like Specification by Example. But either way, if the domain is complex enough, either will cover a need that static, non-executable documentation handles way worse, because old school paper documentation goes stale very quickly. So how does TDD affect design? Mostly by making sure that you aren't writing pieces of code that are so complicated they are untestable, and frankly, you should probably be avoiding that in the first place.