[runawaybottle]

I’ll add to the list:

- Ceremonial unit tests for every little thing. The whole system is buggy as hell and we don’t have any confidence that the unit tests are truly covering critical parts of the app. But alas, test coverage, the god damn Pope that can never be bemoaned.

- I’m not making this one up: A/B testing for an internal enterprise app.

[teddyh]

Test coverage is almost the perfect illustration of Goodhart’s law. Good programming practices do result in high test coverage, coverage is very easy to measure, but very easy to fake with useless “tests”. So, when the coverage is measured, the coverage goes up, but stops being meaningful.

[onorton]

> but very easy to fake with useless “tests”

While it doesn't alleviate the problems entirely, you can also run things like mutation tests that check that your unit tests actually test conditions, rather than just execute all the code.

[nickcox]

High coverage isn't enough but, in my experience, it's a great place to start.

I've written an depressingly high quantity of code in my career that blows up literally the first time it runs. I'd much rather that happen in a unit test than in production.

Any test that exercises a given branch is better than nothing.

[lmm]

Coverage can tell you what you didn't test, but it can't tell you what you did test.

> Any test that exercises a given branch is better than nothing.

I disagree with this. If you have a test that doesn't actually test anything, you can't tell that you're not really testing that branch. No test is better than a bad test because it's easier to fix.

[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