4 ms·
Haven't seen it mentioned here in the comments so I'll throw in — this is one of the best uses for code coverage tooling. When I'm trying to make sure something
by peterldowns 2y ago
Haven't seen it mentioned here in the comments so I'll throw in — this is one of the best uses for code coverage tooling. When I'm trying to make sure something really works, I'll start with a failing testcase, get it passing, and then also use coverage to make sure that the testcase is actually exercising the logic I expect. I'll also use the coverage measured when running the entire suite to make sure that I'm hitting all the corner cases or edges that I thought I was hitting.
I never measure coverage percentage as a goal, I don't even bother turning it on in CI, but I do use it locally as part of my regular debugging and hardening workflow. Strongly recommend doing this if you haven't before.
I'm spoiled in that the golang+vscode integration works really well and can highlight executed code in my editor in a fast cycle; if you're using different tools, it might be harder to try out and benefit from it.
- hinkley 2y agoI don’t mind coverage in CI except when someone fails builds based on reductions in coverage percent, because it ends up squashing refactoring and we want people doing more of that not less. Sometimes very well covered code is dead code. If it has higher coverage than the rest of the project, then deleting it removes for example 1000 lines of code at 99% coverage, which could reduce the overall by .1%. And even if it wasn’t 99% when you started, rewriting modules often involves first adding pinning tests, so replacing 1000 lines with 200 new could first raise the coverage percent and then drop it again at the end. There are some things in CI/CD that should be charts not failures and this is one.