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

Why TDD isn't crap

hillelwayne.com

Post reply on HN
Print view View original

81–90 of 171 posts

Re: Why TDD isn't crap

#81

Post by Fifer82 »

nilkn wrote: post #72
hacker_9 wrote: post #40

Earlier quoted context omitted.

So you disagree with TDD, but you need to rebuild your system from scratch every 5 years? I feel like this is an argument for TDD. As for throwing away tests; Unit tests are meant to be pretty simple - rule of thumb is you can run a thousand tests in ten seconds. Arrange, Act, Assert - they don't need to be complex, they just need to imprint the intent into the codebase. If the intent changes, by all means remove the…

> So you disagree with TDD, but you need to rebuild your system from scratch every 5 years? I feel like this is an argument for TDD. Not necessarily. If the rewrite is only addressing issues that would have been prevented with tests, then sure, this is clearly an argument for TDD. However, if the rewrite is going beyond what could have been provided by tests, then having a large testing system could actually make the…

I agree. My experience is:

1. Wow it made 10k! Lets rewrite

2. Wow it made 100k! Lets rewrite

3. Wow it made 1M! Lets rewrite but let's properly think hard about the future of this product (Introduce tests and more people).

ALWAYS DO TESTING should always be given the context (if budget allows).

Re: Why TDD isn't crap

#82

Post by efdee »

testvox wrote: post #41
k__ wrote: post #35

Earlier quoted context omitted.

"having test play some part in how the code takes shape" That is exactly the point why I don't like TDD. I mean, there are enough constraints that shape the code, why should something artificial like tests shape it too? With mocking and everything you end up writing code for tests and not code for your problems.

If you use mocks extensively in your tests then you probably aren't getting much of the benefit of TDD. Mocks indicate high coupling so using them is just powering though testing your bad design rather then driving good design via testing.

How do you handle dependencies of the class under test then?

Re: Why TDD isn't crap

#83

Post by efdee »

vinaybn wrote: post #60
k__ wrote: post #35

Earlier quoted context omitted.

"having test play some part in how the code takes shape" That is exactly the point why I don't like TDD. I mean, there are enough constraints that shape the code, why should something artificial like tests shape it too? With mocking and everything you end up writing code for tests and not code for your problems.

Tests are not artificial constraints. They are the guarantees which (should) matter most to your users and stakeholders.

I am quite convinced stakeholders couldn't really care less about the guarantees being made by unit tests. Higher level integration tests, maybe.

Re: Why TDD isn't crap

#84

Post by blurbleblurble »

humanrebar wrote: post #51
blurbleblurble wrote: post #31

You know what's awesome about TDD? It means I, a nobody, can contribute to a huge open source project with lots of moving pieces and be pretty confident that I'm not catastrophically breaking anything and that my feature works as intended. That's awesome!

Right. Good tests are a passive communication tool. They communicate expectations. Most of the discussion here revolves around different people having different expectations. I think the "please test" people have a better argument mostly because they're advocating for tools for good communication.

Totally. I used to hate testing. It felt like someone making me do homework I didn't want to do.

Then it dawned on me that I was already testing, the hard way, by opening up a console and manually setting up test conditions over and over and over again, and that I could do this much faster and in a reusable way by writing tests and running them. What an epiphany that was!

I still open up the console all the time. It's a really useful thing. I think ideally, my testing environment would dump me into a full-fledged console if something went wrong, but this is not something I've taken the time to set up.

Re: Why TDD isn't crap

#85

Post by codemac »

davedx wrote: post #63
codemac wrote: post #59

This is a very poorly researched article, and the previous was as well. With people like Capers Jones and others doing piles of studies 30+ years ago, I'm confused why someone says there are no studies on TDD. My bet is the author doesn't have access to the relevant historical papers, and doesn't know they exist.

Could you provide some citations please?

Look up the talk "what we know about software engineering" on YouTube. Also, search for Mills, Cleanroom, and obviously Capers Jones as I mentioned.

I'm on my phone so I can't link a lot, but I maintain that the author should do a lit review of software quality in engineering, and they'll get better conclusions

Re: Why TDD isn't crap

#86

Post by crdoconnor »

hacker_9 wrote: post #11

I expect the reason TDD is so controversial on here is people can't see the long term benefits of tests, and instead only think in the short term. But in the commercial world, code you write can potentially have a lifespan of 30+ years. In this case, making a choice to write tests is the difference between writing a maintainable component in the future vs writing a soul-destroying 'legacy system'. If you agree tests…

>I expect the reason TDD is so controversial on here is people can't see the long term benefits of tests, and instead only think in the short term.

There's a number of reasons why you could try TDD and get frustrated with it because it ends up sucking for you:

* You're using unit tests where integration tests would be more appropriate.

* Your integration tests would take longer to build than the thing you're building itself because you have to set up some sort of elaborate mocking.

* Time is of the essence but quality isn't / your code will be run a limited number of times.

Re: Why TDD isn't crap

#87

Post by Vinnl »

the_af wrote: post #48
Ajedi32 wrote: post #37

Earlier quoted context omitted.

Nah, the code tests the tests just as the tests test the code. If you expect your tests to pass and they don't, something's wrong. (Either with the code, or with the tests.) Same goes for when you expect the tests to fail and they don't.

The code is definitely NOT the test of the tests. It may seem that way because (sometimes) when the code breaks (e.g. fails to run at all), the tests also break. But consider this: what if your tests are poorly written and fail to detect bugs? What if they fail because the test code is buggy? Failing to detect bugs is a bug (undesirable behavior/output) of test code. There are some techniques to address this, for exa…

Note that mutation testing is mostly just an advanced (and more brittle) form of code coverage. The flip side is that code coverage reports can also be considered tests of your tests. Not exhaustive, but I'd argue that unit tests hardly ever are as well - and that's OK.

Re: Why TDD isn't crap

#88

Post by Vinnl »

unnawut wrote: post #78

I have been attempting at TDD on and off for about 3 years. It never really took off for me. I would spend most of the time writing the tests, then implementing the code, then only to find out that a lot of my tests don't make sense, or are overthoughts that don't really add business nor technical value. However, I think I reached my sweet spot just weeks ago. Here is my optimum workflow now: 1) Write test cases (the…

This works very well for me too when I'm reluctant to go full TDD. That said, step 2 isn't necessarily the complete code needed for the tests, so there is some back-and-forth between step 2 and 3, resulting in some test code still being written before the code under test.

Re: Why TDD isn't crap

#89

Post by gilbetron »

mattmanser wrote: post #21
hacker_9 wrote: post #11

I expect the reason TDD is so controversial on here is people can't see the long term benefits of tests, and instead only think in the short term. But in the commercial world, code you write can potentially have a lifespan of 30+ years. In this case, making a choice to write tests is the difference between writing a maintainable component in the future vs writing a soul-destroying 'legacy system'. If you agree tests…

This whole thread is a response to: https://news.ycombinator.com/item?id=15591190 Your points are directly addressed in the pdf. One of his general points being, in practice, the tests become the legacy system instead. And I'd add to that. Given that you've at minimum doubled the code (and doubled the bugs), it seems like a really bad long-term trade off. Also DI does not reduce coupling. I've seen plenty of code wit…

When TDD first started coming out years ago, in an email thread I asked one of the proponents how they handle the fact that tests can easily increase the complexity of a system by adding more code. I was expecting a rational discussion of how to balance tests making your code simpler with tests be a source of added complexity. Instead it was met with anger because I should "count" tests as part of the codebase, and how stupid I was for even considering such a thing.

I still stand by my point. 100 lines of code with 1000 lines of testing code means your codebase is 10x what it would be without the tests. That extra 10x had better result in a hell of a lot of benefit.

Additionally, over the years I've found that easily-tested code sacrifices readability, and that tiny functions isn't always the best way to go. I've gone back to liking larger, more monolithic functions as often I don't want to create a bunch of generic functions for hypothetical use for other projects, I just want some code that fits my needs to a T.

Re: Why TDD isn't crap

#90

Post by hwayne »

blurbleblurble wrote: post #75
the_af wrote: post #53

Earlier quoted context omitted.

That seems to do more with automated testing (unit, regression, integration, etc) than with TDD. It's important not to conflate the two because TDD proponents say that TDD is not primarily about testing .

Thanks for clarifying this. I wasn't aware of the hardcore TDD thing, I moreso just interpreted TDD to be the concept of "write tests as you code".

Yeah. "Pure" TDD is strict cycles of "Write failing test, write the bare minimum of code that passes, refactor", which most studies suggest isn't much more helpful than the "common practice" TDD of "write tests as you code".
Post reply on HN