Or: (If your happiness depends on what somebody else does, I guess you do have a problem. -- Richard Bach, "Illusions")

The BileBlog has an a recent entry calling for the death of the TDD "crowd."

I just wanted to say that I agree with him (about the incorrectness of the arguments, not the death part)

Hani makes several good points, so I am going to explain my thoughts for each one separately.

First he comments on attitude:

The problem with the TDD crowd is that they're unwelcome guests in a world that doesn't want or care about them. I'm very sick of TDD bigots being snooty, getting offended, and angrily tugging at their unmentionables every time they see a unit test that doesn't meet their ludicrous standards for what constitutes a unit test.

So am I. At what point did "finding a good way for me to work" become "Here's what you should do." Going around telling others what they "ought" to do is part of what's wrong with IT now. I have no wish to make it worse by telling others where they're faults lie -- I am too busy dealing with my own. To those who feel the urge to go argue why TDD is the "right" way to write software I have a simple request: Don't. Instead, ask yourself why you feel the need to convince others that you are right -- whether they want you to or not. There are millions of people in the world asking for help, go help them instead of trying to convert everyone to your viewpoint.

Next Hani takes aim at a spurious argument for test isolation:

The TDD asshats will now start furiously chewing on their desks if you try to use any sort of real container in your unit test. To them, that pollutes the test, you're in fact testing the container too and not just your servlet. That, astoundingly, makes it an invalid unit test (or at best, crippled, awkward, unwieldy).

Ad hominem (and rather hilarious) attack aside, this is one of the best arguments Hani makes. If my reason for practicing TDD was to retain the purity of what I tested, I would have given up a long time ago. I do TDD primarily to design my code. I isolate tests to speed them up, and make them easier to maintain. Mocks allow me to keep everything I need in the test for easy reference. Purity is about German beer, not TDD tests.

TDD is not about establishing quality, its about design. TDD tests aren't really unit tests either in intent, or approach (that's why most XP'rs stopped using the term). Hani takes this issue on next:

I do understand what the TDD folks preach; they want their design and functionality to be defined in terms of tests. I wish they'd make it clear that this has NOTHING to do with unit testing.

'nuff said.

Finally, Hani points out the most important reason to do (or not do) TDD:

I don't write my tests first. I know very few people who do. It's awkward, fragile and unintuitive. For those who enjoy it and find that it's none of those things, great!

I think Hani bile shield slips a bit here (perhaps there's really a sensitive and empathetic guy behind all that cynicism). He finds TDD awkward, so he doesn't do it. Yet he doesn't turn and argue against it - he simply says its not for him and grants that if people find it useful, he supports that. Guess what? I don't do anything I find awkward or painful either, and I also recommend people work how they are comfortable. Guess neither of us understand TDD.

Granted Hani and I differ in that I don't find TDD a painful exercise (and those I have worked with have generally liked designing this way too). Perhaps if the TDD zealots stopped obfuscating the practice, treating it like a golden hammer, reinforcing people's beliefs that this is something that must be difficult to be useful, and otherwise pissing people off, more people might actually find something useful in it instead of calling for their deaths. (Just guessing)

In closing Hani braces for the counter-attack and calls us swine (hehe):

Of course, I'm sure that the TDD crowd will now get all indignant, and pontificate about how I just don't 'get it'. Swine!

Well, I am in the TDD crowd, and I think he gets it better than many who claim to. Again 'nuff said.

In closing, here's what I think of software process bigotry:

I care about what people produce, not how they do it. I set out to ensure that the teams I work on (and thus me) are happy and productive, not to convert others to my one true vision. I try to teach people to use TDD by example, but only when they ask me to. I welcome disagreement because it shows the next step toward my improvement. I try to remember that disagreement does not equal stupidity but a different viewpoint.

Trying to shout others down means we lose the opportunity to see their perspective. Thanks to Hani for not simply shutting up. Hopefully other TDD'rs listened to what you had to say -- at least this one did.