Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TDD Doesn't Work

blog.cleancoder.com

Post reply on HN
Print view View original

21–30 of 133 posts

Re: TDD Doesn't Work

#21

Post by AnimalMuppet »

crdoconnor wrote: post #7

tl;dr the recent studies proved that that you're testing first or last doesn't matter, provided you're frequently flipping between writing a test and writing code. The author thinks that TDD is preferable because it helps you maintain discipline. I personally think it's worthwhile besides that because it means you design the API before implementing, meaning it is cheaper to fix API design mistakes. IIRC this aspect w…

And that's one of the things TDD gives you - as you write the test, you have to use the API. If that's painful or even just awkward, it's telling you something...

Re: TDD Doesn't Work

#22

Post by gohrt »

kendallpark wrote: post #4

I'm definitely in the TDD-is-not-a-one-size-fits-all programming style camp and I'm glad to see a study that supports that conclusion. I was at Railsconf when DHH said his bit in 2014. My office and I followed the subsequent debates between him and Kent Beck (since my dev group was largely pro-TDD). Lots of anecdotal arguments. It's nice to see some more quantitative data on this! In my programming experience I've fo…

> Do the TDD fanatics downvote to hell everything anti-TDD?

Did you notice the bias in that question?

Re: TDD Doesn't Work

#23

Post by pooktrain »

liquidise wrote: post #15
pooktrain wrote: post #8

Earlier quoted context omitted.

You say "do what makes you successful" after "I have never let my teams go full TDD". If someone on your team is most successful with TDD, do you still not allow it? re: writing 30% less code - I've found TDD can reduce my percentage of lines of code, as you suggested. Adherence to the "refactoring" part encourages that you reduce duplication, which in my experience has been easier to do with good test coverage.

You are correct. My use of the singular "you" was more directed toward people in their own projects. For the purposes of a team at a company, you can think of it as a collective "us". We do not use TDD. I would say that the most successful teams i have been a part of focus not on automated testing but instead on other collective practices: informal code reviews, diff analysis of every commit, group discussion of data…

Sure, these practices can help build a healthy engineering culture, and I agree with them all, especially collective manual testing.

How do you keep people from doing TDD though? How do you even know they are doing it?

Re: TDD Doesn't Work

#24

Post by keithnz »

GrinningFool wrote: post #16
keithnz wrote: post #5

Earlier quoted context omitted.

so what's your approach to ensuring the software you deploy is correct?

How does TDD prove its correctness? TDD suffers from the same limitations as the code - it generally only covers what you could think of. It's a powerful tool, but I think any belief that sufficient test coverage (in most common cases) actively proves correctness is misguided. In the general case, even full test coverage proves only that you've tested for the conditions you expect - but does nothing to verify the cor…

Correctness is by definition, you say what your code should do in various situations. You can then automatically verify that is the case ( using whatever method ). You need to capture "correctness" in some form. For things you can't think of, and then learn about, you add that stuff to your definition of correctness. I'm not arguing for TDD ( or against ), I'm asking if they don't use TDD, what do they do to capture correctness? I'm interested to know. TDD certainly doesn't try to cover correctness at all levels of software deployment, but it does try to capture fine grained correctness.

Sometimes correctness isn't that valuable compared to other criteria as faults can be quickly corrected and have minimal impact. But I think you need clarity about the tradeoffs you make.

EDIT: in some situations things can be corrected quickly.

Re: TDD Doesn't Work

#25

Post by digibo »

kendallpark wrote: post #4

I'm definitely in the TDD-is-not-a-one-size-fits-all programming style camp and I'm glad to see a study that supports that conclusion. I was at Railsconf when DHH said his bit in 2014. My office and I followed the subsequent debates between him and Kent Beck (since my dev group was largely pro-TDD). Lots of anecdotal arguments. It's nice to see some more quantitative data on this! In my programming experience I've fo…

I read the article, but I haven't read the study. The article seems to show that the study is useless - it proves nothing, it's neither pro-TDD, nor anti-TDD. Taking a seemingly strong side of an argument supported by the study, but not commenting on the linked article itself, can explain the downvotes.

Re: TDD Doesn't Work

#26

Post by kendallpark »

digibo wrote: post #25
kendallpark wrote: post #4

I'm definitely in the TDD-is-not-a-one-size-fits-all programming style camp and I'm glad to see a study that supports that conclusion. I was at Railsconf when DHH said his bit in 2014. My office and I followed the subsequent debates between him and Kent Beck (since my dev group was largely pro-TDD). Lots of anecdotal arguments. It's nice to see some more quantitative data on this! In my programming experience I've fo…

I read the article, but I haven't read the study. The article seems to show that the study is useless - it proves nothing, it's neither pro-TDD, nor anti-TDD. Taking a seemingly strong side of an argument supported by the study, but not commenting on the linked article itself, can explain the downvotes.

So I read the study. Martin Fowler is correct that you can't make huge generalizations from the study. But the importance is that someone is actually attempting to get quantitative evidence in an argument that has been largely anecdotal for the past several years. As flagrant as DHH's keynote was, back in the day, I think he was right to compare TDD to a fad diet. Yeah, there are people that will absolutely swear by it. But we really won't know until actual studies are done.

Re: TDD Doesn't Work

#27

Post by kendallpark »

gohrt wrote: post #22
kendallpark wrote: post #4

I'm definitely in the TDD-is-not-a-one-size-fits-all programming style camp and I'm glad to see a study that supports that conclusion. I was at Railsconf when DHH said his bit in 2014. My office and I followed the subsequent debates between him and Kent Beck (since my dev group was largely pro-TDD). Lots of anecdotal arguments. It's nice to see some more quantitative data on this! In my programming experience I've fo…

> Do the TDD fanatics downvote to hell everything anti-TDD? Did you notice the bias in that question?

I'm sorry the sarcastic inflection does not come through the online text.

Re: TDD Doesn't Work

#28

Post by GFK_of_xmaspast »

keithnz wrote: post #5
liquidise wrote: post #2

Commenting on TDD stories here is historically a bad practice, but i'll add my input here. I have never let my teams go full TDD. The reason is that in all my experience, TDD sacrifices a lot of velocity for the sake of automated tests. When i hear about the reduction in total bugs injected, it is a "duh" moment. The fastest way to make a team inject 30% fewer bugs is to have them write 30% less code. That isn't snar…

so what's your approach to ensuring the software you deploy is correct?

"TDD" is not the same thing as "having unit and integration tests".

Re: TDD Doesn't Work

#29

Post by k_sze »

GrinningFool wrote: post #16
keithnz wrote: post #5

Earlier quoted context omitted.

so what's your approach to ensuring the software you deploy is correct?

How does TDD prove its correctness? TDD suffers from the same limitations as the code - it generally only covers what you could think of. It's a powerful tool, but I think any belief that sufficient test coverage (in most common cases) actively proves correctness is misguided. In the general case, even full test coverage proves only that you've tested for the conditions you expect - but does nothing to verify the cor…

"How does TDD prove its correctness? TDD suffers from the same limitations as the code - it generally only covers what you could think of."

Another limitation is that because the tests are (usually?) written by humans, the tests could also be wrong.

So you think your application works, but it turns out that both your application code and your test code were wrong and you didn't catch a bug at all.

Re: TDD Doesn't Work

#30

Post by nercury »

TDD presents a paradox that requires split-brain thinking: when writing a test, you pretend to forget what branch of code you are introducing, and when writing a branch, you pretend to forget you already knew the solution. It is annoying as hell.

You CAN indeed cover all your branches with tests afterwards. You can even give that a fancier name, like "Exploratory Testing". Of course it may be more boring or tedious, but is a perfectly valid way to ensure coverage when needed.

TDD was great for popularizing writing test first; However I much prefer the methodology called CABWT - Cover All Branches With Tests. Let the devs choose the way to do it, because not everyone likes these pretend games.

Post reply on HN