Use overall code coverage conditions as quality gate on Pull Requests

Suggest new features
, , ,
37

Thanks for sharing this feedback. We will take a fresh look at this and share if I have an update.

39

Imposing a requirement on the overall code coverage percentage will inappropriately reject some kinds of pull requests:

  • A pull request that removes unnecessary code that happens to have better coverage than the rest of the codebase.
  • A pull request that improves (eliminating unnecessary verbosity) existing code that happens to have better coverage than the rest of the codebase.

Developers may be encouraged to leave in unnecessary code or to refrain from fixing other issues because of this requirement. Checking code coverage only on new code prevents most of these problems.

To catch mistakes like disabled tests from Jest’s it.only feature, rules like S6426 may be a better choice. For this to work, the rule must not be disabled and SonarQube must recognize the test code as test code (not as production code and also not completely ignored). If similar functionality in another test framework is not detected, consider reporting a separate issue about that.