It's your "Period" that reveals something to me. Like there's no best way than TDD to enforce better design. Like it's the ultimate thing you can do, and behind that there's nothing. Like higher expressivity or code generation cannot even compete with TDD in that regard. Like if you are not doing TDD, then it means your software has bad design.

Automated testing is the raison d'être of the whole blog. TDD is a methodology that also involves automated testing.

If you're going to call it flame-bait, could you expand on some of your ideas or address some of the points made in the article?

>It's first and foremost a design tool.

Care to expand on that? Other than forcing low coupling, I don't really see what TDD does for the design of the code, especially because it emphasizes unit testing, and those are pretty small in the scope of overall design. And even the low coupling is debatable, a good test framework is going to have enough hooks to be able to isolate the unit under test to the point that the surrounding design doesn't really matter to the test.

I can put in 2 cents here. It makes you think about your API up front. Can you do that others ways (write your documentation first, etc)? Of course so do the approach that works for you. TDD just happens to be my preferred approach.

As for "especially because it emphasizes unit testing" that doesn't mean it frowns on integration or acceptance testing. In fact most practitioners I know write high level end to end tests for the core functionality.