Conversely, I struggle to think how coverage could be increased significantly without increasing the test suite size in reality.
I've told this story many times before but at a previous job a senior engineer told me "100% code coverage is useless and you shouldn't go for it" but since he was being dogmatic and not actually thinking about what he was saying he was arguing against something very sensible. I was testing an expert system where everything was large if/else trees encoded in types + configuration. I wanted to make sure I tested all edge cases and activated all of the blocks when they made sense.
I had to fight for that extra coverage and it was, in the end, a massive help.
Think of your code like a heat map. Higher heat on lines that get exercised more often by your tests. It's fine that _some_ code has no color at all, while you some other paths to be bright red in the end, instead of always just going for a uniform orange for everyhing.
The key here is most. Think about your use case before applying anything you read online.
> It's fine that _some_ code has no color at all, while you some other paths to be bright red in the end, instead of always just going for a uniform orange for everything.
This was the logic tree of a device used for health care work. Cost of failure was high. I had very good coverage of all edge cases that other systems could produce and tested a lot of extremes + a DSL for describing the input state.
The important thing here: an expert system is not most programs and the cost of a failure should really drive what your testing methodology is.
Looks like your case is one where 100% coverage is a good thing and the cost paid for it is absolutely acceptable - nay needed to be paid. And you didn't just go for 100% and stop there because you hit some metric but you actually did the thing that's more important too ("data coverage"). Kudos!
Above 80% or 90% it becomes a poor measure.
Coverage can be increased without increasing the test suite by reducing the code base size (within pratical limits obviously)
Personally, I only find coverage as a good indicator of which code still needs to be tested, like forgetting some edge cases or conditional branches.
You've increased test coverage, but was it effective? Eh probably could do something more useful with your time.
(yes this is a contrived example, adjust numbers for your situation)
test("when a metric becomes a target, it stops being a good metric", () => {
runApp(); // look ma, lots of "coverage"!
assert(true, 'No errors!');
}); // unfortunately paraphrased from real codeIf you just want to know that your app is broken, it's far better to monitor your live app (or staging environment or deployment pipeline or whatever) since that monitoring infrastructure can then be leveraged to collect other runtime health data in a more granular fashion.