“Sadly, it’s the “senior” developers that are often most resistent to trying new techniques like TDD - years of doing things a certain has them set in their ways.”
I have an alternate explanation, one I think is much more credible than “old fogies don’t know what’s good for them”. No, it’s that TDD is a teaching tool which benefits beginners much more than it does seasoned veterans. Junior programmers are more likely to get fanatical about TDD because it actually did help them advance the learning curve from complete novice to journeyman programmer. They also likely did it on projects that were easily amenable to TDD, such as college projects or new from-scratch development.
And senior programmers are more likely to say, “huh, this is a practice which will teach me me things I’ve learned long ago and which will force me to program the way I always have. Alright, so why should I bother?”
Sure, you CAN shoehorn any sort of development in the TDD model. So what? It’s still shoehorned in. You don’t get the same benefit that you would, say, with your legendary suite of a zillion tests, each which run in under a millisecond, which cover every aspect of the code in complete isolation from each other. Instead you have something approaching the results of traditional QA, where you have limited tests that try to test things in isolation but usually don’t, with big gaps in coverage and still don’t catch the complex interaction bugs.
You know, the choice is not between “no tests and some tests”. Whenever someone says that I want to slap them. Traditional QA is not about writing no tests. Traditional Dev is not about never writing an opportunistic test when they feel like it. The choice is between some tests and more tests. Are more tests always better? Hell no! I’d rather have no tests than a suite of fragile tests which never catch anything and throw off hundreds of false positives. Granted, more tests are USUALLY better, but you know, those “more tests” don’t come for free. I may WANT to write more tests but choose not to for the same reason I may WANT to buy a Ferrari but I end up buying a Honda Civic – because it’s the best value, and my time and money is better spent elsewhere.
Okay, to sum up. I’m not saying “TDD doesn’t work”. Clearly it does work very well for some people and some projects. What I am saying is that TDD doesn’t work equally well for ALL people and ALL projects. For some combinations of people projects, it’s not worth it for them to go through the exercise. And those people can do less with the wet-behind-the-ears TDD zealots with their condescension, their pity, their starry-eyed idealism and their “if you’ve never tasted the kool-aid you’ll never know what it’s like”.