Live data from Hacker News

TDD Doesn't Work

blog.cleancoder.com

51–60 of 133 posts

Re: TDD Doesn't Work

#51
post #40
post #30

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,…

TDD requires you to write FUNCTIONAL test first, not unit tests you are talking about.

I was commenting on the methodology as I heard and watched it explained by the author (Robert C Martin), as well as the way it was presented in his videos.

TDD workflow is fine; it's not thinking about the pink elephant (the source code) idea that bugs me.

Re: TDD Doesn't Work

#52
post #48
post #46

Earlier quoted context omitted.

You mean me personally? What makes you think so?

Because you said that you can test program manually faster than write automated test case for it. I'm opposite. Human must think, computer must work.

I can write tests. I just prefer not to, for the sake of productivity and preserving sanity. If you disagree that I can write mostly bugless code, I challenge you to find some bugs in my open-source projects :)

https://github.com/ambrop72/aprinter

https://github.com/ambrop72/badvpn

Re: TDD Doesn't Work

#53
post #42
post #41

Earlier quoted context omitted.

How do you KNOW your code is working and bugless?

That's a good question. There are different ways: - Play around with the program intelignetly and observe no bugs (you wouldn't believe how many bugs I've found by that method, that have been missed by very formal verification processes). - Don't call it done until you haven't proven to yourself that the code has no bugs. This is an informal process of self-code-review but which involves quite rigorous thinking about…

> Play around with the program intelignetly and observe no bugs

That's the most sophomore thing I have read in a long time!!!

Probably works OK if you are working alone in a simple product whose whole code mostly fits inside a single brain. Try doing that as part of a team of dozens that make daily changes to a code base of millions of lines and you will very soon earn the title of the most infamous person in the office.

Re: TDD Doesn't Work

#54

Before I go in, I will state that in 99% of the times I'm a TDD hater. Actually I don't even like writing tests after the fact because I just like to build and move on. I could never understand why the ruby on rails tutorial insisted on walking newbies through TDD and skipped all chapters where they start talking about tests when I started learning rails. I still think it's a bad idea to make newbies do all the weird…

Once you release a product that will be used by many customers and developed by many people throughout its lifecycle, which come and go as the time passes, you won't be able to maintain/extend it without a proper testing suite. It's not only about complexity, but also about maintainability. Some tests will also rot in time.

Re: TDD Doesn't Work

#55
post #50
post #47

Earlier quoted context omitted.

How you prove to your peer that you done all of above? How your code is able to pass peer reviews??

Well, I haven't claimed to be able to to that , but to write mostly bugless code :) Though, writing insightful comments in the code helps. If anyone has doubt, you explain in a friendly way why they're wrong (if they are). Though, not all reviewers will study the code suffciently to find possible bugs, and also many findings are not the right/wrong kind but more about style/architecture.

I also doing all of that AND test cases. However, I never use debugger. :-/

Re: TDD Doesn't Work

#56
post #18

Earlier quoted context omitted.

I find that automated tests shine pretty much all of the time, provided they're relatively cheap to build, cheap to maintain and not buggy. Where they fall down is when they're more expensive to build than the code under test and they produce false positives/negatives.

I agree. The problem is that almost inevitably they end up getting more and more expensive to build and maintain while at the same time becoming buggy ;) It's a difficult battle to win. I think you need self discipline to keep limiting yourself to an ever evolving subset that is the optimal ROI. This means over time removing tests that don't add as much value any more. Rewriting some other tests. etc. Human nature th…

Unit tests tend to get more expensive with time (but not always do). Other kinds of test behave differently.

Re: TDD Doesn't Work

#57
post #52
post #48

Earlier quoted context omitted.

Because you said that you can test program manually faster than write automated test case for it. I'm opposite. Human must think, computer must work.

I can write tests. I just prefer not to, for the sake of productivity and preserving sanity. If you disagree that I can write mostly bugless code, I challenge you to find some bugs in my open-source projects :) https://github.com/ambrop72/aprinter https://github.com/ambrop72/badvpn

Your code will not pass my peer review. ;-)

Re: TDD Doesn't Work

#58
(to nobody in particular)

Please the article before commenting.

It's not totally clear from reading some of the comments that people have actually read the article.

It's a good one, please do.

Re: TDD Doesn't Work

#59

tl;dr = someone did a study that used a methodology that confirmed that working in small chunks and writing tests as you go is good, but that it's not very important if you write the tests before the small chunk of code or after the small chunk of code.

Confirmed that if you work in small chunks, it does not matter if you write the tests first or last.

That part about it being good to work in small chunks isn't there.

Re: TDD Doesn't Work

#60

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...

Except that it is not real use.

Might be better than nothing, but if you are designing a reusable API, you'll be better using it on some real code.

Post reply on HN