Replying just to highlight that it's possible, even common, to have a scenario in which:
> "passing tests" doesn't mean anything.
//implementation
var CONSTANTS = {
RED : "red"
}:
//test
test(function () {
assert.strictEqual(CONSTANTS.RED, "red");
});
The worst was that people started doing it with translation strings. So we'd send a config file to the doc team, they'd rephrase something to be clearer, or remove a misspelling, and suddenly tests are failing and the translation string can't be committed until the next day. We had a release build delayed over this once.
Meanwhile, because the coverage report is already showing the code path that displays the string as green, nobody has written tests to figure out if the dialog containing the string actually shows up on screen.
Sometimes I feel like the entire concept of code coverage was just a mistake ;)
The outstanding issue with Java code coverage tools is switch statements, because there are unhandled paths generated by the compiler, but there is an easy solution: don't use switch statements. Enums are basically always a better option anyway.
I use test coverage as part of my workflow. Run my tests with coverage on and make sure my new code is fully covered. Kinda like a sanity check to make sure I'm not missing anything. Or if I'm stepping into old code and I want to see how well it's tested, I'll run the full suite with coverage on and see how bad it is.
The second management starts asking for x% code coverage is when it starts to break down, imo.