4 ms·
We actually hook it into our build process. Basically: * we have 100% code coverage except for some well-defined exclusions (e.g. // LCOV_EXCL_LINE comments to
by rkday 11y ago
We actually hook it into our build process. Basically:
* we have 100% code coverage except for some well-defined exclusions (e.g. // LCOV_EXCL_LINE comments to exclude code that is logically unhittable)
* on each checkin, our continuous integration server (Jenkins) runs the tests and checks that coverage is still 100%
* if not, it fails the build
This means that _every new checkin_ either has unit tests that exercise all the code, or // LCOV_EXCL comments that make it obvious to a code reviewer what isn't covered (and they can then sensibly judge the risk). It's a good way to keep our code quality high, and avoid the possibility that we quietly skimp on unit tests when under deadline pressure. Also, if new members of the team don't realise how important good unit test coverage is, they'll find that out on their first checkin when the build breaks, rather than several weeks in.
- overgard 11y agoWith all-due respect to other philosophies than mine, that sounds like a nightmare. And I like tests. But everything has a cost, and I can't imagine ever getting anything significant done with such a straight-jacket, I'd spend all day tracking down weird compiler quirks. I do a lot of cross platform stuff, and just having warnings as errors (a good idea) means a lot of build fixing because clang and MSVC disagree on things. If I were writing code in MSVC and I had to deal with code coverage reports from clang breaking the build, I would be paralyzed. "Code quality" isn't a thing that can be trivially measured, and in my experience people that fixate on certain metrics tend to miss the forest for the trees.
- rkday 11y agoI can see that it wouldn't always be ideal, but on this (admittedly relatively niche) codebase - core telephone network infrastructure, which we only support on Ubuntu and which we build with GCC - the kind of clang/MSVC incompatibilities you talk about aren't a problem, and the reliability requirements are high enough that it's worth having CI check for 100% test coverage. I think it's a question of field rather than philosophy - someone else in this thread said they do the same thing in avionics.
- Too 11y agoClaiming coverage has anything to do with reliability is just fooling yourself, at least if it's done on line or branch level. Will your 100% line coverage catch the divide by zero bug in this function? int foo(int x) { return 1 / (5 - x); }