Live data from Hacker News

TDD Doesn't Work

blog.cleancoder.com

71–80 of 133 posts

Re: TDD Doesn't Work

#71
post #57
post #52

Earlier quoted context omitted.

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

If it works, then it works. That's the point.

If I don't use it because it doesn't pass my peer review process, whatever that might be, then my competitor will use it and come up with a faster/cheaper solution than my one.

Re: TDD Doesn't Work

#72
post #64

Earlier quoted context omitted.

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

BTW, can you elaborate on the meaning of "sophomore"? I can't find in a dictionary anything other than "second in a series" which doesn't seem to make sense in your use.

Probably means http://www.merriam-webster.com/dictionary/sophomoric

Re: TDD Doesn't Work

#73
post #64

Earlier quoted context omitted.

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

BTW, can you elaborate on the meaning of "sophomore"? I can't find in a dictionary anything other than "second in a series" which doesn't seem to make sense in your use.

Sophomore is the name of the second year in American high schools, so he's basically calling it an comment someone inexperienced would make

Re: TDD Doesn't Work

#74
post #51
post #40

Earlier quoted context omitted.

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.

Robert Martin is author of Agile manifesto.

https://www.quora.com/Why-does-Kent-Beck-refer-to-the-redisc...

The original description of TDD was in an ancient book about programming. It said you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output.

Re: TDD Doesn't Work

#75
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…

You know, I used to be like that. Then I had the revelation that in the time it took to click test something 4 or 5 times I could write test code that could click test in less than 100ms forever.

Re: TDD Doesn't Work

#76
post #61

Earlier quoted context omitted.

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

Right. In large projects some kind of automated tests are indeed useful. But they should not be a substitute for writing working code in the first place, just as an extra level of quality assurance.

Just compare web design before ACID and after ACID. All browsers had working code, but web design was nightmare.

Re: TDD Doesn't Work

#77
post #54

Earlier quoted context omitted.

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.

Agreed, in my case what ends up happening is I start out with no tests but soon the project becomes huge and i have to start writing tests if I want to push stuff without fear. The thing is, most large companies have a QA team so this fear is not super tangible to many developers. And small startups are more focused on building stuff quickly (which they should be). I think this is why this topic has been polarizing.…

> most large companies have a QA team

Not sure what companies you are referring here. Google and Amazon does not have QA team for most of dev team.

I worked at Amazon and now work at Google.

Re: TDD Doesn't Work

#78
post #44

I thought that TDD morphed into ending up with a regression/integration/conformation test suite instead of using tests as specifications written prior to writing products. And even 100,000s of tests won't help you in very advanced applications like cloud/cluster infrastructure as sometimes it's simply too difficult if not impossible to come up with tests (imagine observer effect when your cluster deadlock happens onl…

How do the people who write them know that they work?

Re: TDD Doesn't Work

#80
The author was going somewhere when he began writing about what a developer is thinking about, but, perhaps because he was focused on vindicating TDD, he did not arrive there.

A developer who is writing unit tests must have a good idea of the purpose of the target of the tests, so she is thinking about requirements. Furthermore, if she is writing unit tests for small components (which will often be the case on account of everything being done in short cycles) then a lot of that purpose is contingent on other aspects of the design and how it is all supposed to work together: in other words, she is thinking about design.

If you don't spend some time thinking ahead about big-picture requirements and design issues, you are in danger of going a long way down a dead end.

Post reply on HN