
Do you aim for 80% code coverage? Let me guess which 80% you choose - sturza
https://dev.to/d_ir/do-you-aim-for-80-code-coverage-let-me-guess-which-80-it-is-1fj9
======
hinkley
> If you leave the most difficult 20% untested, then you are building a knot
> of spaghetti code.

This is backward. You don’t leave code untested because you’re writing
spaghetti. You leave it untested because you _wrote_ spaghetti, past tense. If
you’re still writing spaghetti then your commits are most likely lowering code
coverage, not raising it.

If you’re above 80% and climbing, there’s a good chance that new code is being
written at a higher standard. But as the project grows, a new block of code
with 98% coverage does less and less to move the needle.

The main exception being the person who can’t seem to realize when they have
confused themselves. You know the one. Tries to do everything the hard way and
fails because they don’t possess enough surplus clever to do things the hard
way.

But they are also the sort that manages to somehow get full coverage without
asserting anything important.

------
hinkley
I aim for 85% coverage because everyone I’ve ever seen try to go from 20%
coverage to 100% coverage has been caught lying, either to themselves or to
me.

There are many ways to confuse the coverage metric collection. They have
gotten much better but they are not perfect.

Code with zero tests is trivial to discover. The task list practically writes
itself. You can grab a random one and just start testing it. But once code
looks as if it has tests, the cost of discovering that it doesn’t is high,
either in hours expended, or public discovery by customers.

I’d much, much rather have an honest 82% than a bullshit 99.

And the thing is, you are going to be better at writing tests later than you
are now. Why rush to produce all the tests while you are still comparatively
lousy at it?

------
jrjarrett
I've used this metric but intelligently - I've used tools to SEE what is
covered or uncovered.

Simple constructors or accessors that end up not getting coverage are fine, I
believe you can see that you have little risk in not writing test for them. If
you're shooting for package-level tests and you have no separate tests for
POJO's (in Java) - little risk there.

But if you see a big section of exception handling that has not been tested --
that's a sign of a risk. Test that stuff.

------
alexfromapex
Disagree. To most companies, maintaining development speed while catching the
majority of bugs is more important. Everyone wants 100 percent coverage but
it’s often a trade off that doesn’t make business sense.

------
highprofittrade
These are just numbers tech managers throw around to look good to their
superiors. Just hire really good engineers and let them decide what's best.

