xd009642
commented
3 years ago Interesting, I'm currently working on a fairly big feature for tarpaulin so won't have time in the near future to address this but I am open to it as a feature.
I'd probably go with cyclomatic complexity instead of line-count given the cobertura xml format has a field for that and there is a crate to calculate it here. That may also mean services like codecov.io that use the cobertura format may have complexity filtering in their UI as well :thinking:.
There are also some existing functions to remove code from coverage results such as the cfg attributes or excluding whole files if you want to use them in the meantime.
Code Complexity
Often, coverage metrics are misleading due to coverage of a large amount of trivial functionality, and the output for ensuring tests have better coverage for crucial code paths is obscured by the large amount of noise.
For example, here are two samples of code, one which is trivial and therefore the lack of coverage is not significant, especially with the large amount of boilerplate for abstractions a lot of projects have. In the first example, a crucial, very rare code path is not being covered by my tests, showing a crucial lack of coverage. The second, we have an inlined, const, function that is never called in unittesting, but compiles and therefore demonstrates its functionality.
I understand not making this the default: in some cases, coverage of boilerplate is very important. However, it can obscure useful details, making actually analyzing crucial branches that are not covered difficult.
Solution
There's generally two different ways to measure code complexity: the number of lines of code, and measuring the amount of control flow (cyclomatic complexity) exists in code. Being able to configure thresholds for inclusion in coverage reports would make the code coverage reports (and statistics) much more useful for developers looking for ways to improve their code, rather than merely looking to increase coverage metrics.