I'm not sure he is not getting, what Wil says make sense for some softwares. Especially for GUI heavy softwares. Basically he is using beta testing as QA. He makes one excellent point: writing tests take a lot of time. Developper time is expensive, QA testers time is cheap. Also QA always come up with a million ways to twist and bend your application, lots of them might not be considered by developers writting test units.
I think unit testing makes an economic sense for back-end stuff but I don't know if it does so well for GUI tests (in terms of return on investment.)
I've measured and compared the time taken to add similar features with and without test-first. Note that this is not the same thing as what Wil Shipley calls "unit testing." He's right that adding tests after the fact is a long, boring process that frequently does little to find bugs. However, test-first is different. It's not even about finding bugs, though that's a nice side-effect. Test-first is an investment in the code you're writing now and will write in the future. It keeps your mind focused, helps you think about and improve your design, and reduces maintainence costs. So it should be no surprise that in my trials, using test-first was faster and introduced fewer bugs than doing traditional coding.
Adventures in not getting it, but it is a common misconception that "unit tests" (now known in XP circles by the more accurate name "programmer tests (http://c2.com/cgi/wiki?ProgrammerTest)") are dinky and useless -- and anyone who says that has never done test-driven development (http://www.testdriven.com/modules/news/).
Maybe I'm just not enough of a True Believer, but he does have some valid points there. Structured unit testing can be handy, but it's not the second coming of Christ some people would have everyone believe.
His point that "I wrote unit tests" doesn't mean the code is actually very resilient is good.
I don't agree with everything he said, but I think you're overreacting to it -- "this is completely and utterly wrong, every word" is rarely a productive start to a conversation.
'Structured unit testing can be handy, but it's not the second coming... "I wrote unit tests" doesn't mean the code is actually very resilient is good.'
By the same token, just because test-first is a tool rather than a panacea doesn't mean "unit testing is teh suck." Whether he has anything right, Shipley's thesis is indeed wrong. You're right that unit tests are not going to write your code for you, but they are an invaluable tool to a forward-thinking engineer. Those who hold to Shipley's attitude, by contrast, are still caught in the 20'th century.
I think I tend to have a gut reaction against framing things in terms like "forward-thinking" and "still caught in the 20th century".
Forget the I AM THE FUTURE hype. It accomplishes nothing other than letting fans of whatever the flavor of the month is pat each other on the back. Playing burn-the-heretic whenever someone doesn't agree with your pet methodology is even worse.
So many people get too caught up in methodology and trendy process, and it's just annoying and pointless.
Sure, Shipley's thesis is a bit hyperbolic and does need to be read with a grain of salt. Like I said, I don't think he's right about everything. On the other hand, I think it's possible to go overboard in disagreeing with him and end up being just as wrong.
Anyway, I probably spend close to half my time at work writing unit tests. Usually they're at least partially implemented before the code they test is done, and later tests are guided by code coverage tools, with an eye towards fault-injection to cover difficult error cases. I would never ship code or even push it out of my private development branch without an accompanying unit test.
However, I do this because I work in networked storage, and cannot afford to lose customer data to bugs. It's too expensive to recover data and fix things in the field, so everything's extensively tested beforehand.
Other parts of the industry are different, and I'm not going to generalize from my experience to a "everyone must do the same thing or they're useless cavemen" proclamation.
Hi, Nat. I see now that I've used strong language, language that is justified, however. The subject deserves a piece on its own; I won't try to connect the dots for you here. Nonetheless, I do believe my sentiments are justified and will be justified by history. I see good reasons for these conclusions. You seem to assume I see otherwise. You may disagree with my position, and it is my job to persuade you, which I clearly have not yet done. Even so, you would do well to continue considering the statement on it's merits, rather than reducing it to an "I AM THE FUTURE hype" strawman.
chanson
I think unit testing makes an economic sense for back-end stuff but I don't know if it does so well for GUI tests (in terms of return on investment.)
-TimK
-- Jon
His point that "I wrote unit tests" doesn't mean the code is actually very resilient is good.
I don't agree with everything he said, but I think you're overreacting to it -- "this is completely and utterly wrong, every word" is rarely a productive start to a conversation.
By the same token, just because test-first is a tool rather than a panacea doesn't mean "unit testing is teh suck." Whether he has anything right, Shipley's thesis is indeed wrong. You're right that unit tests are not going to write your code for you, but they are an invaluable tool to a forward-thinking engineer. Those who hold to Shipley's attitude, by contrast, are still caught in the 20'th century.
-TimK
Forget the I AM THE FUTURE hype. It accomplishes nothing other than letting fans of whatever the flavor of the month is pat each other on the back. Playing burn-the-heretic whenever someone doesn't agree with your pet methodology is even worse.
So many people get too caught up in methodology and trendy process, and it's just annoying and pointless.
Sure, Shipley's thesis is a bit hyperbolic and does need to be read with a grain of salt. Like I said, I don't think he's right about everything. On the other hand, I think it's possible to go overboard in disagreeing with him and end up being just as wrong.
Anyway, I probably spend close to half my time at work writing unit tests. Usually they're at least partially implemented before the code they test is done, and later tests are guided by code coverage tools, with an eye towards fault-injection to cover difficult error cases. I would never ship code or even push it out of my private development branch without an accompanying unit test.
However, I do this because I work in networked storage, and cannot afford to lose customer data to bugs. It's too expensive to recover data and fix things in the field, so everything's extensively tested beforehand.
Other parts of the industry are different, and I'm not going to generalize from my experience to a "everyone must do the same thing or they're useless cavemen" proclamation.
Less hype. More code.
-TimK