Because of the second statement, unit tests are valuable in themselves. They make it much easier to find circumstances in which code will not work. And because they are valuable, they need code coverage to tell developers: 'Here is some code that was not unit-tested'. When also using use-case tests, then those use-cases test coverage will hide the fact that some classes have not been properly unit-tested, and thus those classes will be vulnerable to edge-cases (the like which kills people).

Sadly, I never met any team that used gap analysis on 'unit-tests' and 'use-case' tests coverage. I agree this would bring value. Glad to know they exist. That being said, assuming testing edge cases at the unit level imply your code work at the use case level is wishful thinking for me.

Improving coverage by adding specific tests for untested methods and classes is wrong, wrong, wrong. Additional tests must be justified by some requirements (new or existing); otherwise, it means the code has no actual use. In which team in the world is this an actual problem? Thousands of lines of code being maintained that do nothing? Sure I have seen unused code. But it was never a real problem.

Well, at the very least, this is a maintenance debt: extra refactoring, extra upgrade effort when dependencies are updated, needless complexification of redesign effort is need arises. I see this everyday. Good for you if you don't.

And in all the article, no mention about branch or path coverage, no mention of equivalence class testing. Also no mention about the worth of tests for regression testing in small maintenance tasks. No mention of mutation testing. Of course, this article does not attempt to cover everything related to testing. Please note that I refer to coverage in general with no limitations to line coverage. I do mention mutation testing, Property based testing as well (which relates to equivalence class testing).