> Code coverage has absolutely nothing to do with code quality.
Certainly you can go wrong by chasing high code coverage, yet I have only one application that I have written that has had zero bug reports filed against it. On a whim I decided to try for 100 percent coverage and in the process found a small pile of bugs. Since then nobody else has found any. At least by that metric it is high quality.
This seems right, Never have I not found bugs while chasing code coverage. When I've pushed for higher code coverage, I usually find some bugs. General Code Review becomes easier when you can see that the person tested all of the edge cases and has a clean 100% coverage on the CR. When the code gets deployed I can generally trust that it's going to work, or get rolled back in a staging environment.
It's certainly possible to make high quality code without tests (see Linux), but simply taking the time and writing tests seems to accelerate development.
This is fine if people are diligent about writing good tests.
If you enforce coverage on a busy team with less experienced or less diligent engineers, you're going to get a lot of "tests" that just pass for coverage purposes and gives false confidence in your code and doesn't gain you anything.
Fair, it's easy to get execution without validation, but ultimately this is where code review matters. The (huge) company that I work at now is the only one that's ever strongly encouraged test coverage, with a general expectation of 85% coverage and 95%+ encouraged.
It's also the only company that I've worked at where you can commit code and get up from your desk.
- Bugs are often found and unreported, leaving the user with a general impression of janky software and damaging your word-of-mouth efforts.
- Some bugs aren't triggered often but are still bad when they happen. Sorting in Python and Java/Android was broken for ages, but not in a way you'd hit often.
- In keeping with the above point, failure rates are exponential in the complexity of your software in the presence of buggy components. Future changes and additions will be problematic on a buggy foundation.
- Many bugs go unnoticed while still causing damage. You know that kind of "oh shit" moment when you compare the last year of payments in one database to another and find duplicates or missing records? You're not sure yet what went wrong, but _something_ definitely wrecked a lot of people's days.
- Similarly with anything involving proper subnormal support, bit-accurate transcendentals, .... If you don't have a good idea what the result was supposed to look like and it was built on a numerical house of cards then you might get lucky most of the time, but some of your outputs are going to be subtly wrong in ways that definitely hurt the business and probably won't be picked up on for ages.
And so on. Maybe it's not worth fixing the bugs in some piece of software (balancing constraints and all that), but there's definitely value to be had.
Certainly you can go wrong by chasing high code coverage, yet I have only one application that I have written that has had zero bug reports filed against it. On a whim I decided to try for 100 percent coverage and in the process found a small pile of bugs. Since then nobody else has found any. At least by that metric it is high quality.