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

241–250 of 346 posts

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

#241

Post by mannykannot »

lobster_johnson wrote: post #73
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…

Code coverage should perhaps not be counted in lines, but in the number of type permutations covered. Then your challenge is determining all the types that _can_ be passed as inputs.

By types, I assume you mean categorically different types of data, rather than the types of the type system that your language recognizes?

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

#242

Post by tumblen »

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…

How do you know what 10-20% to test?

This sort of basic level of decision-making for testing is something I wish I had, but all the tutorials and guides are about 100% code-coverage TDD so it's hard to find a path to to learn reasonable, high ROI testing.

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

#243

Post by fireflash38 »

swalsh wrote: post #229
iamleppert wrote: post #114

The worse the developer, the more tests he'll write. Instead of writing clean code that makes sense and is easy to reason about, he will write long-winded, poorly abstracted, weird code that is prone to breaking without an extensive "test suite" to hold the madness together and god forbid raise an alert when some unexpected file over here breaks a function over there. Tests will be poorly written, pointless, and give…

"The worse the developer, the more tests he'll write." no.... please..... no..... let's not go down this path. Why does everything have to be extreme? No tests, 100% tests... it's all bollocks. The most robust code I've ever written was 100% because of unit tests. It was a little engine that approved the prior authorization for medications. The unit tests didn't cover 100% of the application. In fact the only bit it…

Everytime I've seen these arguments it's been the same:

* Bad coding practices lead to bad tests * Bad test practices make development very difficult, since you're constantly chasing your tail

They're invariably intertwined. Bad tests can be re-written. Bad code can be rewritten/refactored too, but it tends to have a larger impact on the product (you know, the thing that actually makes you money).

However, it seems that a lot of posters see bad tests and say that it's the problem, and therefore most tests are bad. They neglect that bad tests are a smell that what they're testing is probably shit. They're treating (condemning) the symptom, not the cause.

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

#244

Post by TheCoelacanth »

iamleppert wrote: post #114

The worse the developer, the more tests he'll write. Instead of writing clean code that makes sense and is easy to reason about, he will write long-winded, poorly abstracted, weird code that is prone to breaking without an extensive "test suite" to hold the madness together and god forbid raise an alert when some unexpected file over here breaks a function over there. Tests will be poorly written, pointless, and give…

Completely disagree. The worst developers don't even care if their code ends up breaking later; as long as it gets past QA now, that's all that matters.

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

#245

Post by plinkplonk »

lacampbell wrote: post #86
plinkplonk wrote: post #76

Earlier quoted context omitted.

"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 safet…

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

No. I didn't mean to imply or assert anything of the sort. Apologies if I inadvertently gave offense. You seem to be reading meanings into my reply that aren't there.

I don't know you from Adam. You asked a question in your post. I answered as best as I could.

That said, your latest statement

"I'll admit confusion on things like ocaml polymorphic variants and haskell monads,"

does seems to imply that you don't have much real world experience with static type systems in production (nothing wrong with that) since neither is an arcane concept or particularly difficult to understand.

If you haven't worked extensively with Haskell/Ocaml/SML etc, and you are extrapolating properties of 'static type systems' from those of Java or C++ then your idea of such type systems 'stunt prototyping and exploration' might make sense.

The rest of your comments are extrapolations from misunderstandings - not born of practical experience. My answer was based on (strictly) personal experience. Which is why I said "in my experience". I gladly concede that YMMV.

again, I was just answering your question in your original comment. I didn't mean to "imply" anything and used "probably" to mark my uncertainty about your real world experience with Ocaml/Haskell etc style static type systems.

I have extensive experience with both dynamically typed languages (mostly Python, Lua and Scheme) and statically typed languages (mostly Haskell and SML, besides Java). I answered out of my experience.

YMMV. And that is cool.

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

#246

Post by JoeAltmaier »

EugeneOZ wrote: post #240
JoeAltmaier wrote: post #238

Earlier quoted context omitted.

A concise word for 'older and lazy' might be 'experienced'

Not always, not in this case definitely.

I don't know; disagreement over whether everything must be tested isn't enough to call it 'lazy'? Its an easy dart to throw. But remember, everything you don't do leaves room for more progress elsewhere. Its an optimization problem.

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

#247

Post by sidlls »

scottschulthess wrote: post #140
iamleppert wrote: post #114

The worse the developer, the more tests he'll write. Instead of writing clean code that makes sense and is easy to reason about, he will write long-winded, poorly abstracted, weird code that is prone to breaking without an extensive "test suite" to hold the madness together and god forbid raise an alert when some unexpected file over here breaks a function over there. Tests will be poorly written, pointless, and give…

So the worst of us developers out there write tons of tests? We wish. Who cares if it's 80% or 100%, i'd rather inherit a codebase with lots of test coverage than without.

And what about test coverage for the tests? You do realize that tests are also code, right? They have bugs, maintenance overhead, and all the other things code has.

The worst code bases I've seen have more test code than code being tested. People try to write tests to cover every condition or input and in systems of even modest complexity that isn't possible, or at least not feasible in a finite time.

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

#248

Post by misja111 »

userbinator wrote: post #156

But remember nothing is free, nothing is a silver bullet. Stop and think. I'm going to be the one to point at the elephant in the room and say: Java. More precisely, Java's culture . If you ask developers who have been assimilated into a culture of slavish bureaucratic-red-tape adherence to "best practices" and extreme problem-decomposition to step back and ask themselves whether what they're doing makes sense, what…

It might even make sense for many of those enterprise developers to have a set of best practices that they can blindly follow. Not every developer has that many years of experience or is sharp enough to be able to identify the cases where unit testing makes sense, and those where it doesn't.

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

#249

Post by nathan_f77 »

ruleabidinguser wrote: post #53
mikestew wrote: post #28

The tragedy of 100% code coverage is that it's a poor ROI. One of things that stuck with me going on twenty years later is something from an IBM study that said 70% is where the biggest bang-for-the-buck is. Now maybe you might convince me that something like Ruby needs 100% coverage, and I'd agree with you since some typing errors (for example) are only going to come up at runtime. But a compiled (for some definitio…

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

I've been working on a 1-man project with maybe 5% test coverage, just for some critical libraries that I ended up refactoring a few times. There's actually one little library that has 100% test coverage and super detailed error messages, because that's where many of the bugs seemed to happen.

I also have a simple integration test that just clicks through everything and makes sure nothing crashes.

Not having a lot of tests can be painful. Especially when you're learning new languages or frameworks, you almost always want to go back and rewrite some code (or just reorganize it into different files), and it's really nice to have tests when you do that. So sometimes that gives me the motivation to start writing up a bunch of tests, and then after that I dive in and refactor everything.

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

#250

Post by misja111 »

circlefavshape wrote: post #162

/me raises hand on the pro-testing side I've been programming for a living since 1996, and only recently started to do TDD in the normal sense of writing unit tests before writing code. I've found to it to be an enormous help with keeping my code simple - the tests or the mocking getting difficult is a great indicator that my code can be simplified or generalised somehow I argued for functional instead of unit testin…

I agree that TDD and unit tests can help you when writing code. But once your code has been written, are all those unit tests still useful? Or do they get in your way when you do large scale refactoring?

I have seen quite a few codebases with loads of unit tests that might once have been useful, but now were just slowing down development. Many of them should have been thrown away and replaced by a couple of functional tests, however the sunk cost fallacy always kicked in, nobody wanted to throw away all the hours of work that had gone into making them and not to forget the precious code coverage as well.

Post reply on HN