[oxfordmale]

I have seen bad unit test being introduced when engineering management starts enforcing a threshold (80% coverage). Often developers will scramble to test trivial methods, such getter and setters, but will not write any suitable tests that actually cover the business logic. It is even worse when management only enforce a 80% coverage for new changes. In those scenarios developers go out of their way to encapsulate changes in a separate class to avoid having to test the original codebase in a meaningful way.

[bennyelv]

I think most people, including the managers are aware of the problem you've highlighted. What's the solution?

[lmm]

The solution is don't measure test coverage. Measure something you actually care about, like minutes of downtime.

[oxfordmale]

Every time a bug is found I ask my team to write a unit test for it to prevent regression for that bug.

During peer review I encourage Engineers to verify that the actual business logic has been tested, for example calculations.

If done correctly, a low unit test coverage can actually be of more quality than enforcing an 80% threshold