This is a bit of a tangent, but having seen TDD fail more often than not ("fail" meaning it just seems like writing tests is busywork for no real benefit, and eventually as the deadline looms devs just stop writing tests) I'm wondering if there's an approach where the tests are NOT written by the person writing the code... e.g. a senior lead or QA person of some sort writes the tests, which become attached to the stories that the devs implement.
Wouldn't that mean you lose one of the reputed benefits of TDD: writing tests as a way of exploring the problem space, informing the design of the code under test? More generally while there is a place for testers that are at arm's length from the implementation, giving the implementor some of the testing responsibility (TDD or otherwise) has the benefit of investing the implementor directly in the QA process.
You really shouldn't do it that way. Tests should be written by the guy that wrote the code, while the problem the code solves is still fresh in mind. If you don't, then you'll have to re-understand both the code and the problem it solves before you'll be able to write good tests for it. That means TDD.
You TDD because the code you write with it is code that is easily tested. If you write the tests after you write the code, then you'll have to refactor the code just to get it to the point where its testable without digging really deep into your classes. It will be painful, and the effort will be abandoned.
I thought I wrote good, clean code. Then I started unit testing. Now I wouldn't think of writing code first. The procedural mess that my brain comes up with inevitably results in hard to refactor, hard to test spaghetti.
The word "driven" like the word "oriented" are the problem. Once you make it a religion, or otherwise elevate any one idea above all else, you suck away most of the value from it and preclude yourself from deriving value from competing ideas.
