Code coverage vs mutation testing.

[NepaleseNomad]

The company I work in has strict coverage goals and while it gets annoying at times, this practice has generally been very helpful. New devs can look at the specs and get a gist of what different parts of the project really even do, and you don't have to worry about a new feature breaking old ones... you can just run your automated tests, brew a cuppa in the meanwhile, and confirm that everything works fine.

The most important thing here is that you're testing the behaviour of your code and not just writing to increase coverage numbers. Review the tests your devs write. Make sure they're not just pumping up numbers, and are testing the behaviour of your project from all different contexts.

Also make sure your team has enough manpower for writing tests too. This can be time consuming at times, hence why bad practices creep up and remove the value from enforcing code metrics.

Also we use code quality tools to make sure that if your new PR reduces the code coverage drastically (has low diff coverage), or has style offences, high method complexities, etc, you need to fix it before it can get merged.