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

TDD Doesn't Work

blog.cleancoder.com

Post reply on HN
Print view View original

81–90 of 133 posts

Re: TDD Doesn't Work

#81

Post by jacques_chester »

ambrop7 wrote: post #42
TylerE wrote: 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

What if the computer encoded your knowledge?

> Don't call it done until you haven't proven to yourself that the code has no bugs.

What happens when the software changes? Do you repeat every single desk-checking exercise to ensure nothing has broken?

Do you even remember every click, every experimental input?

Can you prove that you do?

> This is an informal process of self-code-review but which involves quite rigorous thinking about the behavior of the code.

I trust that smarter developers than me are smarter developers than me.

But I am dumb. I assume that the code is smart and that my mental simulation of the code, which my brain helpfully and invisibly patches on the fly, is correct.

But my mental simulation is frequently wrong. So I wrap myself in explicit statements of what I think the code does. Then I make those explicit statements executable. And then I run them frequently.

And frequently, I realise again that I am dumb and I should leave the flawless coding to others.

Re: TDD Doesn't Work

#82

Post by jacques_chester »

marcosdumay wrote: post #60
AnimalMuppet wrote: post #21

Earlier quoted context omitted.

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.

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

Agreed, this is why tests should be driven from the outside in.

But at the unit level, tests are often the first contact with production code. Tests are dumb and setting up complicated stateful worlds is painful and tedious.

It becomes easier to simplify the production code to simplify the test code, than to just write the first thing that comes to mind.

Re: TDD Doesn't Work

#83

Post by taneq »

keithnz wrote: post #5
liquidise wrote: post #2

Commenting on TDD stories here is historically a bad practice, but i'll add my input here. I have never let my teams go full TDD. The reason is that in all my experience, TDD sacrifices a lot of velocity for the sake of automated tests. When i hear about the reduction in total bugs injected, it is a "duh" moment. The fastest way to make a team inject 30% fewer bugs is to have them write 30% less code. That isn't snar…

so what's your approach to ensuring the software you deploy is correct?

You can use automated unit and integration testing without doing "TDD". The overhead isn't even particularly high; you have to test any piece of code you write anyway, so you might as well put in a tiny bit of extra effort and have unit testing.

Re: TDD Doesn't Work

#84

Post by lisivka »

bitL wrote: 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…

Why you think that debugging and fixing deadlock in cluster in production (of multibillion business) is easier and cheaper than writing of functional test case? Maybe you just prefer trips to angry customer versus boring office work. :-/ http://www.reuters.com/article/us-nasdaq-halt-tapec-idUSBRE9...

Re: TDD Doesn't Work

#85

Post by lisivka »

z92 wrote: post #71
lisivka wrote: post #57

Earlier quoted context omitted.

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.

Peer review is not for filtering software. Peer review is process which used by (professional) developers to help each other to catch bugs and share experience and best practices. Basically, I said him that I found bugs and/or bad practices in his code.

Re: TDD Doesn't Work

#86

Post by spronkey »

YZF wrote: post #18
crdoconnor wrote: post #13

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…

Hmm, I think this arises from a mindset that doesn't treat tests as part of the code that should be maintained and refactored.

You always have to be removing and refactoring tests if you are changing your production code. Changed a sorting algorithm? Good, go and have a look at your tests to see whether there's anything that doesn't need to be tested anymore, or edge cases that need to be tested now that the algorithm has changed.

Red -> Green -> Refactor

Re: TDD Doesn't Work

#87

Post by MaulingMonkey »

ambrop7 wrote: post #38

I must be one of the very few people who can write working and mostly bugless code and without writing any kind of test. Writing tests feels like the most wasteful and possibly harmful thing to me (like by people forcing dependency injection etc. where otherwise unneeded). I don't really know what to think of the situation? Is this how it has always been? Do most software engineers really have no idea what they're do…

> I must be one of the very few people who can write working and mostly bugless code and without writing any kind of test.

Or you may be using a different definition of "mostly bugless" than the rest of us.

I do gamedev. The ability to patch post-release is not a given, even today, for all platforms. Crashes, corruption, progress blockers, etc. are all VERY BAD in this environment.

I see bellow you're writing network code in C. I don't suppose you've done any fuzz testing? Run with address sanitizer? Static analysis? We live in a world of exploitable 1-byte buffer overflows. Maybe not such a big deal for a throwaway blog server, but perhaps a bit scarier if you might be facing HIPAA fines, or running industrial equipment.

A very important note here: Mostly bugless as far as you're aware and mostly bugless in actuality are two very different things. Without testing, I'm not sure how you can have any confidence that you're in the latter camp.

Re: TDD Doesn't Work

#88

Post by spronkey »

cocktailpeanuts wrote: post #67
bitL wrote: 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.…

Yeah... QA teams aren't really the norm anymore. Not to mention that classical QA isn't nearly as effective when developers aren't also performing their own QA.

Small startups that focus on quickly building stuff have to decide whether to take on more technical debt in order to get something small out the door quickly, or settle on a maintainable velocity over time. Some begin at the former and move quickly to the latter once their MVP is out the door. Some never get to move because they sink under the weight.

Re: TDD Doesn't Work

#89

Post by spronkey »

c3RlcGhlbnI_ wrote: post #32

Oh man, it is really funny that he ends it with telling people to read the study. To clarify the linked study is attempting to replicate https://dl.acm.org/citation.cfm?id=1070834 , THE seminal study in Test Driven Development. Well to be more precise it was replicating an existing replication of that study which failed to replicate the original results. They were trying to modify the design so as to account for issu…

Probably because they have a sense of humour, and the conversational style makes it more entertaining to read...?

Re: TDD Doesn't Work

#90

Post by spronkey »

maxxxxx wrote: post #12

You can also write "Methodology X doesn't work always". All methodologies work well for some situation and for others they don't. In my view TDD is great for a lot simple things and algorithms and you can structure your code in a way that most of the code is inherently testable. But when things are so complex that you don't even know the correct architecture upfront, TDD is a killer.

If things are that complex, sounds like you need to be doing some discovery work (spikes) first to break the problem down. Then you can use TDD again :-D. So, I guess you're right - if you don't know wtf you're supposed to be doing, TDD is a killer. But then, so is anything else.
Post reply on HN