> The problem with TDD is that if it is NOT a common point of change, TDD adherents often say that you should introduce DI anyway to make testing easier.
To the extent that's a problem, its not with TDD, nor with DI, but with the particular people giving the advice. Why do people think that "Some of the people who follow X give bad advice Y" is a criticism of X when Y is not something that that X requires?
This is a very insidious comment. You have actually committed the logical fallacy as your position is "All TDD proponents do X". When someone points out, no "Some TDD proponents do X and many of us TDD proponents think X is bad practice" you blame them of the No true Scotsman fallacy, when in reality your position is the one claiming a universal property about TDD.
Not sure if I'm qualified to appoint a cannon but I can tell you of the books that were very influential to me with regards to TDD:
Test-Driven Development by Example, Kent Beck. This came out in 2002 and I haven't read it since then but at the time it really influenced a lot of my TDD thinking. I expect if I read it now I'd have some complaints based on my decade of experience with the process.
Growing Object-Oriented Software, Guided by Tests, Freeman & Pryce. Much more recent and includes more modern thinking about TDD with acceptance/integration tests.
Working Effectively with Legacy Code, Michael Feathers. A great book for dealing with TDD when you aren't doing green field development. He is a bigger fan of Mock Objects than I am, but he illustrates some examples when mocking is the most appropriate response to the current requirements.
All that said, TDD is like any other software methodology. It is a set of patterns and principles that each practitioner interprets for themselves. At it's core though it's pretty simple, automatic verification of specifications are as important as implementation of the specification for any sufficiently long lived, complex software system. Writing those verifications first provides, design, process, and management advantages over the historical process of writing them last and has a high correlation with well factored code. That's it, no doctrines about unit vs integration tests, mocking out DB access or 100% code coverage.
"Where is the data supporting this claim? I don't believe it is true."
This is one central premise of TDD and is not proven or disproven yet. What we can say is that previous software methodologies were lacking, and cannot prove or disprove their superiority over TDD with regards to this statement. If you distill all debates about TDD down to their essence, it revolves around this premise.
I am fine with someone being skeptical of this claim, but I would prefer if they offered A) a measure we can use to test this hypothesis and B) a contrasting methodology that performs better with regards to the measurements provided in A. The single biggest outstanding problem in software engineering is finding a metric by which we can judge software quality objectively. Because it is such an elusive goal other less precise proxies for software quality have been proposed to stand in for the more complex metric. TDD hangs it's shingle on "testability". Even though this has obvious defects, I've seen no evidence for any other objective measure as a more precise indicator of software quality and quite a few advantages to "testability". Namely, it is measurable.
"Why do you think so many of us feel that it is an ideology? Are we seeing ghosts and imagining the whole thing?"
No, I'm sure that you have encountered well meaning but flawed practitioners of TDD. Your skepticism of their process doesn't bother me. What bothers me is your (and DHH's) painting of all TDD folks as cultists. I don't believe this stuff because Uncle Bob told me to believe it. I believe it because my experience shows that rigorous use of TDD practices trend toward better software than a lack of rigor outside of an objective measure for software quality.
If you have an alternate rigorous approach that you believe trends (or better yet is provably) better in software quality, by all means outline it. I know that TDD is flawed and am happy to find its successor.
Let me ask you this, prior to the rise of TDD, how prevalent do you think automated testing was? If it was very prevalent why is it only after the rise of TDD that automated testing became a central part of any build workflow and the entire concept of Continuous Integration/Deployment developed?
In my experience, automated testing prior to the rise of TDD was not wide spread. But maybe I was seeing ghosts and imagining that.
Neither of us ever said all TDD folks are cultist. We are both tired of being told that we are absolutely doing it wrong if we don't practice TDD. For an example of people telling us this please see this talk by bob Martin and jump to the 58 minute mark. http://m.youtube.com/watch?v=WpkDN78P884
Bob is not an obscure figure by any stretch of the imagination. You have admitted to having no real data to back up the claim that writing tests first leads to better code, yet we have bob here telling us we are absolutely wrong if we don't follow his religion.
> Why do you think so many of us feel that it is an ideology?
Probably because you've run into cargo cult practitioners that treat it that way -- the same as every methodology that's become known outside of a narrow initiating group has -- and human perceptual biases tend to overemphasize and overgeneralize the most extreme examples.
To the extent that's a problem, its not with TDD, nor with DI, but with the particular people giving the advice. Why do people think that "Some of the people who follow X give bad advice Y" is a criticism of X when Y is not something that that X requires?