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

21–30 of 171 posts

Re: Why TDD isn't crap

#21

Post by mattmanser »

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 with DI that's just injecting like 30 things, which is obviously therefore coupled. It just makes it really obvious, but DI itself has massive downsides.

If you've ever worked with bad programmers and seen it in the wild now, I'm sure we can agree DI and TDD doesn't stop bad programmers writing bad code. In fact, all it seems to do is make even more of a mess.

Not only do you have to pick apart the bad code, you have to start dealing with carefully moving methods to the right places because DI can make it hard to figure out what's being used where, and then on top of that tests break all over the place because they're entirely dependant on the implementation instead of the functionality.

Re: Why TDD isn't crap

#23

Post by FLUX-YOU »

latch wrote: post #9
weego wrote: post #6

TDD isn't bad at all for a mature product where you have clear requirements for additional feature development and granular developer tasks. I've just seen a lot of it where a product is still in broad strokes development and developers get stuck between whether having tests written based on early assumptions are correct and the code should conform to those, or whether new ways of thinking that invalidates the early…

There's some truth to this, but it's also possible that the team just wasn't very good at writing tests. It's not easy to do well. Changes will break tests, but given that changes are applied one at a time (you're not erasing your ./src folder, dumping in new code and expecting all your tests to pass), then it should be possible to keep the tests up to date. If a few changes break many tests, then tests might be over…

Getting good at TDD requires being bad at TDD for a while, which requires someone to write bad test code at some point.

But if the entire population as a whole is still having problems with TDD for as long as TDD has been around, then it needs to be a niche methodology.

Our decisions to adopt methodologies/technologies can't revolve around the perfect case of a crack A-team of developers who are good at everything they do.

Think of the mediocre developers!

Re: Why TDD isn't crap

#24

Post by grandalf »

My view is very pragmatic: Some code is far easier to write quickly and correctly using a TDD approach.

In other cases the cost of refactoring with TDD is very high if any significant design or architecture changes occur, so in those cases I find it is useful to stabilize the broad strokes/patterns a bit before investing to much in tests.

Re: Why TDD isn't crap

#25

Post by hacker_9 »

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…

What exactly is your experience working in a commercial environment? When the updates you ship can affect tens of thousands of customers? In these situations, 'Sods Law' often comes to mind - "what can happen, will happen". If you have a defect in your untested code, you can absolutely bet it will come out at the most painful time possible in front of all your clients. Being blamed for that kind of stuff is a stressful way to live your life, much nicer to have tests shout at you instead.

* and to reply to your edit: of course tests break when you change the code they are testing! But after reviewing the broken tests, you see the intent and re-adjust the test. But what often happens, is you realise you didn't fully understand the code previously, and actually after reading the test you need to undo your refactoring as it didn't make sense in the first place.

Re: Why TDD isn't crap

#26

Post by zaphar »

Clubber wrote: post #20
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 forgot who said it but it goes something like, "any code without unit tests is legacy code."

Which by definition means your tests are legacy code. It's turtles all the way down. For what it's worth I do think Unit Tests provide value.

Re: Why TDD isn't crap

#28

Post by apo »

The problem with many TDD critiques is that they offer no alternative. The original presentation:

https://www.youtube.com/watch?v=DQBf6li1hww

is a case in point. Presenter takes what he believes to be TDD's four main points, some of them strawmen, and mocks them. He does make some good points, but here's the problem: he offers no alternative.

If you're not writing tests as you go, that you run before every commit (or before you move onto the next thing), then what is your standard for putting code into a production repository?

Re: Why TDD isn't crap

#29

Post by anon1385 »

DanielBMarkham wrote: post #18

My journey with TDD started with hater, moved to skeptic, and is currently on cautionary-supporter. It's a design methodology, not some new way of unit testing. In fact, I think the more you think of TDD as being testing, the more you're probably missing the point. Modern OO languages are full of hidden dependencies and perverse side effects. The only sane way to write clear and maintainable code is to write the spec…

>It's a design methodology, not some new way of unit testing. In fact, I think the more you think of TDD as being testing, the more you're probably missing the point.

Weirdly it seems to be the loudest advocates of TDD who are the most confused about this.

Re: Why TDD isn't crap

#30

Post by ozim »

hacker_9 wrote: post #25
mattmanser wrote: post #21

Earlier quoted context omitted.

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…

What exactly is your experience working in a commercial environment? When the updates you ship can affect tens of thousands of customers? In these situations, 'Sods Law' often comes to mind - "what can happen, will happen". If you have a defect in your untested code, you can absolutely bet it will come out at the most painful time possible in front of all your clients. Being blamed for that kind of stuff is a stressf…

Pick the tool for the job, if your experience is with things that last 5+ years then ok. I work on a system which is 5 years old and all things from 5 years ago are not relevant. Actually I am working on it only for 3 years now but we pretty much each year rebuild whole thing. With minor things going in and out. Of course we spend a lot of money on automated tests but those tests had to be thrown away because of amount of changes in the system.
Post reply on HN