TDD being imposed in every quality discussion?

Following this discussion I posted my opinion on the matter.

When you have a "simplest thing that could possibly work" the first fit can be a good answer, but it could also be a horrible one. That is where refactoring comes in, and I must admit I'm pretty astounded that nobody mentioned it so far.

TDD means "let me think what this should do... ok I'll write a test that uses this class... there you have the class... ok it works... LET'S ELIMINATE ALL DUPLICATES AND SEE IF WE CAN SIMPLIFY IT FURTHER".

TDD helps quality not only because your software works, but also because it is simple and easy to understand (then to modify). TDD should not be imposed in every quality discussion, but it surely is a very good means to reach quality; writing tests surely is time consuming, but it is well invested time: you're paying for quality. As Philip Crosby said, quality is free but only to those who are willing to pay heavily for it. That's why also Clean Room works, because you're willing to pay.

To quote,

code quality is a function of thought and reflection, not bug prevention.

Sadek Drobi replied that

Code quality is not only about code simplification, but also and most importantly about reflecting correctly the domain (see DDD). TDD is applied to units, you can not build a coherent quality code while thinking locally. That is why TDD is not the "Tool" to quality code. Quality code is a result of good design skills (thorough domain analyses), a lot of discipline, and Functional tests.

TDD is not necessarily applied to units (I know I wrote on InfoQ that I agreed, but I was thinking of Unit Testing and not about TDD), but it's true you cannot build a coherent quality code while ONLY thinking locally. But it surely helps, and this is particularly true if when Sadek talks about functional tests he is referring to automated functional tests.

Sadek then pointed out how TDD is about short cycles and thinking locally, supporting this idea quoting Beck, and stressing the point that TDD does not produce quality code per se and reiterating the importance of design skills, domain analysis, discipline and functional tests.

Again, I agree with him: TDD surely helps to produce good code but is not "the" tool. I mean, if you have a perfectly analyzed class which perfectly represents a domain object (I'm fond on DDD too) but you find it difficult to be tested, probably there is a slightly different and slightly better metaphor to describe it (and maybe an SME can help in defining it). Being able to write a test for a class before actually writing it kind of "forces" you to have an attitute just like the one Sadek describes: you have to analyze the domain with a lot of discipline, because with TDD you are actually saying "what am I expecting from this piece of code? what is the expected behavior of the real object it represents?". Of course, you must also have funcional tests, and having good design skills is almost mandatory, otherwise one would blatantly miss the point of the whole question.