An important element of TDD is that it wasn't supposed to be prescriptive. It's a tool/technique to use. Sensible people know when to use it and when not to. Even Beck (who many here and elsewhere assume is dogmatic about TDD) has said on many occasions he doesn't use it 100% of the time and wouldn't use it 100% of the time.
That's not dogma, that's the technique. If you aren't writing the test first then you aren't doing TDD, and that's fine. There's nothing wrong with not doing TDD at all if that's what you choose.
The dogma most people see or claim to see is that TDD is meant to be used everywhere (or nearly). Which some fools, yes, believe. But they're just that, fools. People who use their brains (aka, non-fools) know them to be fools and do what works for them and the circumstances because they spend some time thinking about things instead of parroting a dogma (or an anti-dogma).
> The dogma most people see or claim to see is that TDD is meant to be used everywhere
And yet TDD preachers are never drawing the boundaries for TDD applicability. They are always extremely vague: "sometimes I see that TDD doesn't work for the problem that I'm solving and I don't use it". Well, how do you see it? What types of problems is it bad for?
If TDD works, they take credit. If it doesn't work, "it's just a tool" or "you used it wrong".
It is literally impossible to prove that TDD doesn't work. Which makes it a religion.
I mean, how can he? You're the one that knows your system so you have to be the judge on whether TDD is appropriate or not for it, or for parts of it. He says as much in his talks on TDD and in his book. You have a brain, use it, don't expect him to think for you on systems he has no knowledge of.
