Test Coverage Insights
Achieving high test coverage, often exceeding 80-90%, is a hallmark of effective test-driven development. Increasing coverage post-factum can lead to significant challenges, particularly if the project lacks a modular structure. Relying on separate teams to add unit tests can dilute code quality and misalign expectations, ultimately undermining the benefits of a cohesive testing approach.In this clip
From this podcast
Software Engineering Radio - the podcast for professional software developers
SE-Radio Episode 324: Marc Hoffmann on Code Test Coverage Analysis and Tools
Related Questions
Are there any drawbacks associated with the tracking code coverage you mentioned about gaming the metrics, other things people should look out for?
Do you happen to remember the interesting bugs you have uncovered by increasing test coverage, something that's particularly stayed in your mind?
It's not right now, as I said before, if you want to increase the test coverage after the effect, you lose a lot of benefits, like creating correct code from the beginning or creating proper APIs. This is all benefits if you practice test first. So adding codecraft rich after the fact to a project is always tough, especially if the structure of the project does not allow. So testing or adding coverage after the fact is something I really don't recommend, which is really tough and typically goes along with refactoring the original codebase to have actually testable components.