Giving Up on TDD • Hacker News Board

Re: Giving Up on TDD

#31

Post by facepalm » Sat, Mar 19, 2016, 5:07 PM UTC

And communism would work if only people would do it properly. It seems to me that kind of argument could be made about anything. "It only didn't work because you didn't do it properly".

Doesn't it work for Homeopathy, too? "It would have worked if you hadn't passed it through the x-ray scanner at the airport" or "it would have worked if you had taken the medicine while doing a handstand".

In the end doing it right becomes so complicated that you need to hire an expert to do it for you. Wonder if that was the point all along - basically marketing.

Re: Giving Up on TDD

#32

Post by Ace17 » Sat, Mar 19, 2016, 5:11 PM UTC

ryanbrunner wrote: post #6

There's definitely some good points here, but I have a huge issue with this point: > Something that is hard to test is badly designed. In my experience, TDD has a natural tendency to favour decoupling at all costs, and TDD zealots will push de-coupling units as an unqualified positive. And if your metric is "good design = easily testable and low coupling" it certainly looks that way. This mindset fails to take into c…

Would you have an issue with "Something that is hard to prove correct is badly designed"?

Re: Giving Up on TDD

#33

Post by sago » Sat, Mar 19, 2016, 5:11 PM UTC

ktRolster wrote: post #10

ryanbrunner wrote: post #6

There's definitely some good points here, but I have a huge issue with this point: > Something that is hard to test is badly designed. In my experience, TDD has a natural tendency to favour decoupling at all costs, and TDD zealots will push de-coupling units as an unqualified positive. And if your metric is "good design = easily testable and low coupling" it certainly looks that way. This mindset fails to take into c…

His point, as phrased, is correct though, something that is hard to test is badly designed. You need to be able to test your software in some way or another. Even if you've proven its correctness, you still want to put it through some basic sanity tests (as Donald Knuth pointed out).

Yes, but it misses the point of the criticism.

The issue isn't whether the final product is difficult to test. It should be roughly as easy to test the final product no matter the implementation strategy.

The problem is that TDD requires a royal-road of testing. No code can be written without tests for that specific piece of code. So you can only build the whole out of components that are testable in isolation. The claim is that this excludes architectures that don't provide such a step-by-step path of testing.

This interacts badly with the 'make everything an API' idea. You end up with these functionally small units with over-engineered APIs rather than something more complex, more efficient, and easier to refactor as a whole.

Re: Giving Up on TDD

#34

Post by msie » Sat, Mar 19, 2016, 5:19 PM UTC

jblow wrote: post #5

For many paragraphs, I thought this was a parody of TDD defense, but then it turns out it wasn't. His 'defense' of the point is basically: Look, when you do TDD you have to put a lot more work into the tests than you thought! It is not just a simple thing! Okay, fine, but ... Before embarking on TDD, the programmer had a picture in his head of what the costs+benefits of this change would be. Now you are telling him t…

Most software out there has been done without TDD.

Re: Giving Up on TDD

#35

Post by Ace17 » Sat, Mar 19, 2016, 5:20 PM UTC

facepalm wrote: post #31

And communism would work if only people would do it properly. It seems to me that kind of argument could be made about anything. "It only didn't work because you didn't do it properly". Doesn't it work for Homeopathy, too? "It would have worked if you hadn't passed it through the x-ray scanner at the airport" or "it would have worked if you had taken the medicine while doing a handstand". In the end doing it right be…

Some disciplines are hard to do properly, and easy to do wrong. It's a mistake to dismiss them just because the return on investment isn't immediate. We're mostly programmers here, we're not supposed to be afraid of steep learning curves!

Re: Giving Up on TDD

#36

Post by barrkel » Sat, Mar 19, 2016, 5:20 PM UTC

This is an argument against a straw man, IMO; people who have a problem with TDD don't (or shouldn't) have a problem with testing, or creating a design that is testable.

What TDD is specifically poor at is design. Test Driven Design literally means your tests drive the design of the system, rather than any other consideration, like reducing API scope, reducing complexity, reducing configurability (yes, excess configurability is a bad thing, and TDD tends to encourage it). TDD in particular won't drive insightful designs, because insight is a product of a fertile and well stocked mind meeting a problem domain - it does not emerge organically out of tests.

Re: Giving Up on TDD

#37

Post by m_fayer » Sat, Mar 19, 2016, 5:22 PM UTC

ryanbrunner wrote: post #6

There's definitely some good points here, but I have a huge issue with this point: > Something that is hard to test is badly designed. In my experience, TDD has a natural tendency to favour decoupling at all costs, and TDD zealots will push de-coupling units as an unqualified positive. And if your metric is "good design = easily testable and low coupling" it certainly looks that way. This mindset fails to take into c…

Just the frequency of certain memes... "interfaces", "design this Design that DESIGN", "composition", "too coupled", "too decoupled", all points me in the direction of excessive use of DI, indirection, and as you say - explosion of tiny "single purpose" types.

I've worked on many such code bases. I don't deny the benefits in testability and extensibility, but I think the benefits have always been outweighed by the difficulty of onboarding new developers, the fact that few people manage to develop a big-picture understanding of how the whole thing fits together, and the proliferation of YAGNI-violating code that ends up being written.

Re: Giving Up on TDD

#38

Post by sago » Sat, Mar 19, 2016, 5:29 PM UTC

To me, TDD means:

1. No functionality is coded without a failing test.

2. Only code the minimum functionality to make the test pass.

It does not mean 'test more' or 'write tests'.

So I'm not sure more than 10% of this 'defence' bolsters the method at all. Seems like the normal rhetorical bait and switch - you pretend that your opponent is criticising testing and respond by defending some more or less vague notion of tests, with no substantive defence of TDD beyond "you didn't try hard enough." The example of the pacemaker, for example, has no relevance to TDD whatsoever.

Re: Giving Up on TDD

#39

Post by facepalm » Sat, Mar 19, 2016, 5:34 PM UTC

Ace17 wrote: post #35

facepalm wrote: post #31

And communism would work if only people would do it properly. It seems to me that kind of argument could be made about anything. "It only didn't work because you didn't do it properly". Doesn't it work for Homeopathy, too? "It would have worked if you hadn't passed it through the x-ray scanner at the airport" or "it would have worked if you had taken the medicine while doing a handstand". In the end doing it right be…

Some disciplines are hard to do properly, and easy to do wrong. It's a mistake to dismiss them just because the return on investment isn't immediate. We're mostly programmers here, we're not supposed to be afraid of steep learning curves!

Sure, although my heuristic for trying new Software methodology tends to be "does it make things simpler?". That article made my head hurt...

Re: Giving Up on TDD

#40

Post by khushia » Sat, Mar 19, 2016, 5:37 PM UTC

c0achmcguirk wrote: post #18

jblow wrote: post #5

For many paragraphs, I thought this was a parody of TDD defense, but then it turns out it wasn't. His 'defense' of the point is basically: Look, when you do TDD you have to put a lot more work into the tests than you thought! It is not just a simple thing! Okay, fine, but ... Before embarking on TDD, the programmer had a picture in his head of what the costs+benefits of this change would be. Now you are telling him t…

> As usual my advice on this is: look at the people who build things you find highly impressive, and study how they did it. This is much more fruitful than reading the output of people who want to spend all day telling you how to program (which leaves very little time for them to build software that is impressive, i.e. they never even test their own ideas!) "Uncle Bob" Martin has built a lot of impressive things. Mos…

I've been using FitNesse heavily at work for the past few years, and I've been surprised by how buggy we've found it.

We have over 30,000 tests and we've had to rewrite part of it because it memory-leaked so badly. Unfortunately the company has strict rules against contributing back to Open Source projects.