I don't see why a fanatical anti-rant is any better than a fanatical rant.
There's this theory out there that Agile projects can refactor fearlessly because there's this immaculate suite of tests that can sound the alarm the second the smallest regression gets introduced. But anyone who's actually tried it knows that it's mostly just a fantasy.
Poppycock. My project has an extensive test suite that we rely on to make major design changes with alacrity, just exactly the way that unit-test advocates advocate. We couldn't dream of doing what we're doing without it.
It's true that not every module of every system responds equally well to this style of testing. It's true that putzing around revising test infrastructure for the nth time really sucks. But these are points that belong in a serious discussion, the kind that recognizes tradeoffs.
cashto's post was a "serious" effort to disperse the cloud of dogma surrounding unit testing and TDD. I hardly think that lashing back with "poppycock" is driving the conversation in the direction of "serious discussion".
cashto emphasized that unit testing is useful for teams with non-expert programmers (viz. his comment about the Dreyfus model of skill acquisition). Many of us are non-experts who benefit from working with the TDD training wheels on; it's O.K. to be less a Jedi All-Star hacker. But the phenomenal programmers, the men and women who were 10 times better than me, could not be bothered with TDD, even through the endorsed it for mere mortals.
To paraphrase the TDD credo of “no test is worse than having no tests”, we can assert that blind faith is not better than no faith at all.
The training wheels analogy was the weakest part of the article to me. TDD isn't a teaching tool, and the fact that they useless to people in a very specialized niche doesn't really say anything about their general value.
I also notice reference to writing tests after the fact. I understand TDD to involve writing tests first. That's how I practice it anyway.
That's just poisoning the well. Yes, X is fine if you're an idiot is exactly what you would say if you didn't want to have a conversation about something and would rather shut down discussion.
this is one of his worst arguments. I find it almost exactly the opposite. I've been programming for almost 20 years and I am considering myself an expert. and many people around seem to agree ;).
most of the beginning was spent w/o any kind of unit testing. But I find it that I do more and more testing with time, and I'm sure as hell I'm not becoming a weaker programmer that suddenly needs the training wheels ;)
> My project has an extensive test suite that we rely on to make major design changes with alacrity, just exactly the way that unit-test advocates advocate. We couldn't dream of doing what we're doing without it.
My experiences are the same as yours. I've refactored code where the unit tests caught that the new structure introduced subtle logical inconsistencies in the program. The unit tests meant I caught this immediately; without them I would have had to wait until subtle and hard-to-fix bugs emerged.
On a different project, I've been able to play around with the structure of the code, secure in the knowledge that my regression test suite will tell me when I fuck things up.
Tests, when done well, are a lifesaver, and essential to any large complex codebase.
> But these are points that belong in a serious discussion, the kind that recognizes tradeoffs.
There's this theory out there that there are creatures that aren't birds but somehow fly through the air using wings. Anyone who has looked for these mythical "bats" knows that they are just fantasy.
Here we see the risk of asserting something isn't real just because we haven't ourselves seen it. I've held a bat in my hands, and I've had my butt saved countless times by tests I've written.
There's this theory out there that Agile projects can refactor fearlessly because there's this immaculate suite of tests that can sound the alarm the second the smallest regression gets introduced. But anyone who's actually tried it knows that it's mostly just a fantasy.
Poppycock. My project has an extensive test suite that we rely on to make major design changes with alacrity, just exactly the way that unit-test advocates advocate. We couldn't dream of doing what we're doing without it.
It's true that not every module of every system responds equally well to this style of testing. It's true that putzing around revising test infrastructure for the nth time really sucks. But these are points that belong in a serious discussion, the kind that recognizes tradeoffs.