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

131–140 of 171 posts

Re: Why TDD isn't crap

#131

Post by AnimalMuppet »

hwayne wrote: post #90
blurbleblurble wrote: post #75

Earlier quoted context omitted.

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".

It's not more helpful as tests than "write tests as you code". But "pure" TDD is more helpful as a guide to low-level design. I'm not sure that most studies can quantify that.

Re: Why TDD isn't crap

#132

Post by 59nadir »

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!

All projects that have been created using TDD have tests, but not all projects that have tests have been created using TDD. You're saying that having tests is good and I would assume most people agree... But that doesn't mean that TDD is automatically great. It's the DD part a lot of people find themselves skeptical towards.

Re: Why TDD isn't crap

#133

Post by the_af »

root_axis wrote: post #94
the_af wrote: post #48

Earlier quoted context omitted.

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…

> what if your tests are poorly written This seems like tautological reasoning. Naturally, if you write bad tests then they won't be effective, but that seems like a poor argument against testing. That's like saying "Yes, bypass surgery could save your life, but consider this: what if the surgeon is reckless and kills you on the operating table?". Obviously, there is a minimum expectation that the surgeon will follow…

If it seems like a poor argument against testing, that's because it's not meant to be one! It's meant to be an argument against the notion that "production code tests the tests". It's also an argument for making sure your tests are effective.

> Naturally, if you write bad tests then they won't be effective

But how can you tell if your tests are effective, i.e. if you wrote "good tests"? Production code alone is not enough; you cannot tell if a test is green because everything is ok or because it's buggy/incomplete. You must introduce some degree of quality control in your test code.

Re: Why TDD isn't crap

#134

Post by AnimalMuppet »

agentultra wrote: post #55

The only thing I disagree with in this article is the leeway given to supposedly legendary programmers who can somehow write bug-free code without tests, specifications, or an inkling of communication with others. First, it's probably not true. Linus Torvalds is not a legendary human being who can write critical systems without a single flaw. He relies on legions of human beings to carefully check and review every li…

I think it's more than just "specification driven development". The question is, does your code match the specification? What is your objective evidence that it does? (Yes, I know, a test is not perfectly objective evidence. It's better than "looks like it should work", though.)

Re: Why TDD isn't crap

#135

Post by tdbgamer »

k__ wrote: post #93
tdbgamer wrote: post #76

Earlier quoted context omitted.

I am generally for TDD, but I don't think APIs really need heavy code coverage. That said, testing the input/output directly doesn't work well because now a single change the output data (adding a field to the JSON for example) will call tons of tests to fail. I usually use or create some JSON serialization/deserialization classes and use those to generate fake data and ensure that the API returns 200 responses. That…

Nice, thanks :) Do you have any good resources on testing? Books/articles etc.? I often have the feeling the only people who write about this stuff are the die hard TDD gurus.

No problem!

I did read Clean Code by Robert Martin. He's definitely in the "die hard TDD guru" category, but there are still useful examples to be extracted from the book.

Besides that, I mainly learned a lot of testing tricks in the wild, reading through Github projects. My learning process now-a-days is mostly:

1. Discover a really cool trick or concept I didn't know existed in a Github project. 2. Research the hell out of it. 3. Try to use it in some personal example project.

Re: Why TDD isn't crap

#136

Post by humanrebar »

bunderbunder wrote: post #122
humanrebar wrote: post #105

Earlier quoted context omitted.

> ...is a roundabout way of saying, "Java", or other static languages with a similarly anemic type system... I agree. In my experience, it's how the median developer writes code, though. Even in more flexible languages they'll reach for type hierarchies and abstract base classes. I've seen people create these things in languages like Lua and Javascript that don't really need them. I think TDD-like approaches make the…

Further agreement. I haven't looked at a textbook on programming recently, but I'm worried that the standard is still to actively teach new developers to program this way, even though we've _known_ for decades that towering piles of subclasses invariably collapse under their own weight. That said, I still wouldn't lay this tendency for damaged design at the feet of static typing in general. Not when some of the most…

I don't blame statically typed languages. But, yeah, they are a bit more unforgiving if you need to refactor your way out of that mess is all.

Re: Why TDD isn't crap

#137

Post by the_af »

Vinnl wrote: post #87
the_af wrote: post #48

Earlier quoted context omitted.

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.

I disagree.

Coverage tests how much of your code is exercised by your tests. Mutation testing is (one way) of testing how effective your tests are -- i.e. how sensitive they are to bugs in your code. It follows that good tests must have both good coverage and good effectiveness, but the two are not the same.

Re: Why TDD isn't crap

#138

Post by eric_h »

lowbloodsugar wrote: post #130
eric_h wrote: post #126

Earlier quoted context omitted.

When I write a test after altering/adding code, I will generally stash the altered application code, and run the test I wrote on unaltered app code to confirm that it fails. As long as one maintains decent version control discipline, you can be pretty confident that the test is valid with this technique. (It does get a bit more difficult when there are schema changes, but then it also encourages good discipline and v…

That's good. I suggest that you're doing unnecessary work (having to stash and unstash) when you had "broken" code at first, but at least you are testing your tests, so well done. In my experience coaching teams on TDD, its quite easy, when writing code first, to add more code than is needed to solve the problem. And then only the problem is tested for. Meaning that there is code that is not tested. Maybe an if state…

Oh absolutely. I've done my fair share of "pure" TDD, but my style has evolved over the years to not always favor a pure approach (usually in the interest of time).

It really comes down to the nature of the problem - if I foresee a chance that the final architecture is not immediately obvious, I'll start breaking down the problem into small pieces and TDD the units, then the integrations.

I guess I'm of the opinion that not everything needs TDD, but everything does need diligence - my code after doing years of TDD has improved drastically, whether or not it was strictly test driven. Merely considering whether it will be easy to reliably test the code improves it, IME.

Re: Why TDD isn't crap

#139

Post by mattmanser »

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…

Had over a million people use my code last year, when I checked for vanity. 12 years commercial experience.

I'm effectively the tech lead for two startups, one getting about 750k users per year, the other 250k. Freelancer, but I do a lot of time for 2 clients at the moment.

Both were projects started by other people, but a significant chunk of the code is mine now (one of them I've virtually totally rewritten from VB.Net to C#) and the other I've done huge amounts of refactoring to fix big performance problems, reducing the "main" pages from 10 sec load times for complicated orders to 250ms.

I've also refactored a lot of javascript for both of them without any tests, significantly improving client-side compile times and page load times.

I played with unit tests a few years ago, one of my clients has some, but we mainly don't add any new ones and they never catch anything[1].

[1]That's a slight fib, one caught a bug last month for the first time in the 1.5 years I've worked for this client. It would almost certainly have been caught in testing though.

Re: Why TDD isn't crap

#140

Post by hacker_9 »

gilbetron wrote: post #119
hacker_9 wrote: post #98

Earlier quoted context omitted.

> 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. Adding more code != more complexity. Complexity comes from high coupling between code, that doesn't separate concerns, which make it difficult to untangle, aka. spaghetti. Unit tests are mean to be simple, and anything they test will be no more complicated that how the system will ac…

Again, this is the argument made to me over 10 years ago, and again, they are wrong. While it is possible to add more code and not get more complexity, it is very difficult. Generally speaking, adding code adds complexity. Full stop. Excellently executed TDD will reduce overall complexity, but I almost never see that level. Rather, TDD's ability to catch bugs is mostly enough to reduce bugs (and other benefits) overa…

Tests make clear the intent of the code, how else can you get that exactly? And the next time you have to fix a broken unit test, think of how much time it has saved you by constantly running autonomously as part of your build process.
Post reply on HN