Giving Up on TDD
blog.cleancoder.com
Giving Up on TDD
1–10 of 112 posts
Re: Giving Up on TDD
#2> but he said he was just using it for some home projects
I think here lies the biggest problem. For small/hackish projects you barely get any benefits from test driven development but still have the higher costs. Test-driven development means that you will spend more effort while developing, but will have to spend less on maintaining in the long run.
The fun part about home projects is that you don't really have to think about maintenance at all and you can just hack things away until they work for you.
PS: you should write out acronyms once in the beginning of an article
Re: Giving Up on TDD
#3Title is slightly misleading, so for anyone reading the comments first, this is Uncle Bob's rebuttal of yesterday's "Giving up on test-first development", in the form of a Q&A.
Original discussion here: https://news.ycombinator.com/item?id=11310711
Re: Giving Up on TDD
#4Q: Are you sick of the Socratic method?
A: Oh God yes.
Q: What's wrong with it?
A: It's overly verbose, condescending, and allows you to give the appearance of resolving a debate when all you've actually done is talk down to a sock puppet.
Re: Giving Up on TDD
#5For many paragraphs, I thought this was a parody of TDD defense, but then it turns out it wasn't.
His 'defense' of the point is basically: Look, when you do TDD you have to put a lot more work into the tests than you thought! It is not just a simple thing!
Okay, fine, but ... Before embarking on TDD, the programmer had a picture in his head of what the costs+benefits of this change would be. Now you are telling him the costs are WAY higher. So a successful defense would have to then make the case that the benefits are also WAY higher.
But he doesn't. Because the benefits aren't higher, in fact they are lower (as is the case with every well-intended scheme in the history of anything.)
As usual my advice on this is: look at the people who build things you find highly impressive, and study how they did it. This is much more fruitful than reading the output of people who want to spend all day telling you how to program (which leaves very little time for them to build software that is impressive, i.e. they never even test their own ideas!)
Re: Giving Up on TDD
#6There's definitely some good points here, but I have a huge issue with this point:
> Something that is hard to test is badly designed.
In my experience, TDD has a natural tendency to favour decoupling at all costs, and TDD zealots will push de-coupling units as an unqualified positive. And if your metric is "good design = easily testable and low coupling" it certainly looks that way.
This mindset fails to take into consideration the fact that tightly coupled things are often simpler to understand and reason about. They're more closed to extension, sure, and harder to test in isolation, but a straightforward process that acts like a "black box" and performs a job simply in a few lines of code is often better than the class explosion that rigid TDD often encourages. And what's the value of keeping things open to extension if the only thing that is going to reasonably extend them are tests?
A good illustration made by DHH as part of one of his anti-TDD tirades is here: https://gist.github.com/dhh/4849a20d2ba89b34b201
Anyone who can honestly say the latter example has a better design has a very different opinion on "good design" than I do.
Re: Giving Up on TDD
#7Q: Are you sick of the Socratic method? A: Oh God yes. Q: What's wrong with it? A: It's overly verbose, condescending, and allows you to give the appearance of resolving a debate when all you've actually done is talk down to a sock puppet.
Q: Why should that be different than any other type of rhetoric?
A: If you want truth, read a scientific study, not a blog.
Re: Giving Up on TDD
#8Q: Are you sick of the Socratic method? A: Oh God yes. Q: What's wrong with it? A: It's overly verbose, condescending, and allows you to give the appearance of resolving a debate when all you've actually done is talk down to a sock puppet.
"It's overly verbose, condescending, and allows you to give the appearance of resolving a debate when all you've actually done is talk down to a sock puppet."
I agree with your criticism of the article's style. But to be fair, if you're arguing with yourself (as the author is), it's not really the Socratic Method, which is a dialog with another person. If you don't get to control what questions the other person asks, it makes for much a more interesting conversation.
Re: Giving Up on TDD
#9Q: Are you sick of the Socratic method? A: Oh God yes. Q: What's wrong with it? A: It's overly verbose, condescending, and allows you to give the appearance of resolving a debate when all you've actually done is talk down to a sock puppet.
Q: Why should that be different than any other type of rhetoric? A: If you want truth, read a scientific study, not a blog.
Q. Are there actually proper studies done by and of proper developers writing proper (ie not trivial crap) code which demonstrate the pros and cons of TDD?
Re: Giving Up on TDD
#10There's definitely some good points here, but I have a huge issue with this point: > Something that is hard to test is badly designed. In my experience, TDD has a natural tendency to favour decoupling at all costs, and TDD zealots will push de-coupling units as an unqualified positive. And if your metric is "good design = easily testable and low coupling" it certainly looks that way. This mindset fails to take into c…
His point, as phrased, is correct though, something that is hard to test is badly designed. You need to be able to test your software in some way or another. Even if you've proven its correctness, you still want to put it through some basic sanity tests (as Donald Knuth pointed out).