I've never heard of this before. Where does this come from and why did they suspect this would be indicative of anything?
People who like to talk about the "proper" way to develop software tend to like it.
People who run open source projects tend to either like it or bow to peer pressure.
But people working on in-house and enterprisey stuff? Yeah, not so much there.
This depends a lot on your corporate development culture, even for in-house enterprisey software.
I suspect you are working from a limited sample size there.
That is absolutely incorrect, in my experience.
It's defining the term "code coverage" to be the ratio of lines covered by tests to the total lines.
> why did they suspect this would be indicative of anything?
If anything, it's a useful feedback mechanism. e.g. "Gee, we wrote sixteen unit tests for this module but we're still only at 34% coverage. Ohh, I see it now -- framistan.cpp doesn't get used by these tests at all. We should write a test that enables framistan mode!"
If you don't have tests, it is an extremely manual process to change anything about your codebase (including dependencies) and have any confidence that you haven't broken things. Once you write tests, code coverage lets you figure out what code is not being tested.
I think it goes deeper than "the conditions you forgot to write" although that's part of it. A developer's test suite tends to make assumptions and these are the same assumptions that exist in the production code. If your assumptions about usage, or input, or edge cases are poor then the tests you write will be poor too and in that case 100% coverage isn't worth much. Big reason I'm a fan of things like QuickCheck in Haskell.
Early 1960's or so!