2 ms·
> Code coverage has absolutely nothing to do with code quality I'm going to disagree respectfully here. I don't think hard-and-fast rules on code coverage are
by kccqzy 2y ago
> Code coverage has absolutely nothing to do with code quality
I'm going to disagree respectfully here. I don't think hard-and-fast rules on code coverage are useful (e.g. must achieve 90% coverage before merging), but just having code coverage run automatically and its results displayed is useful. When I add an "if" check and one of the branches isn't covered for example, I start to think what if some junior engineer didn't understand the reason behind this "if" check and decided to delete this check altogether? If no unit tests fail after deleting this check, that junior engineer might not have enough context to judge whether this check is needed in production.
- mdaniel 2y agoYou actually brought to my attention a metric that I hadn't previously considered but now desperately want: branch coverage. I don't need 90% of lines covered, because one cannot measure coverage of missing lines /* BadImpl.java */ if (theFile.exists()) { doTheAwesome(theFile); } // uh, and else ... what? /* BadImplTest.java */ @Test public void looksGoodTestCoverage() { theFile.create(); instance.runIt(); println("hurray, 100% coverage"); } versus if the coverage tool was able to artificially rewrite the code to be this way, it would show up as not covered: if (theFile.exists()) { ... } else { }
- randomdata 2y agoYou're really speaking about documentation quality, though. The most horribly written code ever written can still do a good job of documenting what the "if" does. I think the real takeaway here is that code quality doesn't really matter. The most horribly written code is still quite fine to work with if well documented.