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

The tragedy of 100% code coverage (2016)

labs.ig.com

Post reply on HN
Print view View original

81–90 of 346 posts

Re: The tragedy of 100% code coverage (2016)

#81

Post by dvirsky »

BigJono wrote: post #71
ruleabidinguser wrote: post #53

Earlier quoted context omitted.

70% coverage... I don't know if I'm going to be able to give up my 0% coverage 1-man projects...

I'd recommend aiming for 10-20% on those projects, and also for startups trying to rapidly push an MVP out. Tests have diminishing returns. You want to hit the absolute most crucial ones that give you plenty of bang for buck and even save you time. That means finding the (usually small handful) of functions that implement your most crucial and most complicated business logic, and writing tests for them. Anything past…

Agreed. If you're a small start-up in a hurry and <4 devs, the best strategy would be to write top-down smoke tests on your API that will actually tell you when things break, even if not exactly where. Their actual derived coverage might be pretty high.

Re: The tragedy of 100% code coverage (2016)

#83

Post by jondubois »

Agreed. I would rather have 5% test coverage that checks against all risky edge cases/inputs than 100% test coverage that checks against arbitrary, low-risk inputs.

Writing tests to confirm the simplest, most predictable use cases is a waste of time - Those cases can be figured out very quickly without automated testing because they are trivial to reproduce manually.

Re: The tragedy of 100% code coverage (2016)

#84

Post by joelthelion »

penpapersw wrote: post #16

I think a bigger epidemic is we're putting too much emphasis on "do this" and "do that" and "if you don't do this then you're a terrible programmer". While that sometimes may be true, much more importantly is to have competent, properly trained professionals, who can reason and think critically about what they're doing, and who have a few years of experience doing this under their belt. Just like other skilled trades…

That's why I'm highly skeptical when I hear the word "best practices".

Sure, the intention is good, but it promotes mindless repeating of patterns over thinking about what really helps.

Re: The tragedy of 100% code coverage (2016)

#85

Post by plaguuuuuu »

BigJono wrote: post #71
ruleabidinguser wrote: post #53

Earlier quoted context omitted.

70% coverage... I don't know if I'm going to be able to give up my 0% coverage 1-man projects...

I'd recommend aiming for 10-20% on those projects, and also for startups trying to rapidly push an MVP out. Tests have diminishing returns. You want to hit the absolute most crucial ones that give you plenty of bang for buck and even save you time. That means finding the (usually small handful) of functions that implement your most crucial and most complicated business logic, and writing tests for them. Anything past…

As long as that 10-20% is the more complex bits, and you are capable of picking out which bits are complex, it's IMO better to do that and spend the time saved on other shit that increases maintainability and reliability. Killing tech debt, killing your teammates, whatever.

Re: The tragedy of 100% code coverage (2016)

#86

Post by lacampbell »

plinkplonk wrote: post #76
lacampbell wrote: post #41

Earlier quoted context omitted.

Valid point. I don't think I could write low-bug count code faster in statically typed scala than I could in unit tested ruby though. I mean I am well aware of what you're telling me, and it's obvious to me that having the compiler automatically check certain properties is a win. And yet, when push comes to shove, to get something done I'm more likely to reach for ruby. It's something I've never come up with a good e…

"Does static typing stunt prototyping and exploration?" Not in my experience. It is probably about what you personally find hard/uncomfortable/unfamiliar.

But you're kind of implying that I feel that way because either I don't use static typing much, or I haven't learned it well, aren't you?

I've used static typing much more than dynamic. I'll admit confusion on things like ocaml polymorphic variants and haskell monads, nevertheless I wouldn't say I find static typing hard as a rule. But surely the point of static type checking is to constrict what you can do for safety and performance reasons. And surely the cost of that is you have less freedom - even when in the exploration phase

Re: The tragedy of 100% code coverage (2016)

#88

Post by kasparsklavins »

cbanek wrote: post #18

I've had to work on mission critical projects with 100% code coverage (or people striving for it). The real tragedy isn't mentioned though - even if you do all the work, and cover every line in a test, unless you cover 100% of your underlying dependencies, and cover all your inputs, you're still not covering all the cases. Just because you ran a function or ran a line doesn't mean it will work for the range of inputs…

Tests are not meant for ensuring it works with all inputs. You cant simply just throw values at it hoping its all okay.

To prove it works with all possible inputs, there are other tools at your disposal.

Re: The tragedy of 100% code coverage (2016)

#89

Post by reledi »

I've found that some bootcamps are responsible for this attitude as they preach to have 100% coverage. And no one really questions the experienced and heavily opinionated teacher.

It's good to use hyperbole black and white when teaching so the point comes across easier. But they should be made aware of caveats before they graduate at least.

Re: The tragedy of 100% code coverage (2016)

#90

Post by ubernostrum »

cbanek wrote: post #18

I've had to work on mission critical projects with 100% code coverage (or people striving for it). The real tragedy isn't mentioned though - even if you do all the work, and cover every line in a test, unless you cover 100% of your underlying dependencies, and cover all your inputs, you're still not covering all the cases. Just because you ran a function or ran a line doesn't mean it will work for the range of inputs…

I only have one piece of code for which I can say true 100% coverage exists: a library that works with HTML/CSS color values, and which ships a test that generates all 16,777,216 hexadecimal and integer rgb() color values, and runs some functions with each value.

However, I don't run that as part of the normal test suite. It only gets run when I'm prepping a new release, as a final verification step; the normal runs-every-commit test suite just exercises with a selection of values likely to expose obvious problems.

Post reply on HN