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?
> 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.
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.
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.
5 comments
[ 34.3 ms ] story [ 491 ms ] threadThere 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?
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.
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.