4 ms·
I have seen bad unit test being introduced when engineering management starts enforcing a threshold (80% coverage). Often developers will scramble to test trivi
by oxfordmale 5y ago
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 5y agoI think most people, including the managers are aware of the problem you've highlighted. What's the solution?
- lmm 5y agoThe solution is don't measure test coverage. Measure something you actually care about, like minutes of downtime.
- oxfordmale 5y agoEvery 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