"Every single line of code that [we] write should be tested. Period."
But that's not enough either. A single line of code can be executed in many different contexts, depending on what the state of the system is - choice and ordering of user actions, files existing or not, localization differences, etc. A unit test that executes a line of code for only one situation doesn't go very far to ensure that this line of code will be bug-free when run in a realistic setting. And a single line of code can do a lot of work if it's a call to a system service or an external library API.
Yup. Every true professional realizes 100% code coverage is a fool's errand for this exact reason. Coverage is a useful metric. It's not the end-all or be-all, and anyone who claims it is doesn't understand the law of diminishing returns.
>>> If we don’t have 100% coverage, we will not know whether our code really works.
Um... your code might not work even with 100% code coverage.
Also, I think I read somewhere that enforcing 100% code coverage makes developers to write dumb tests that don't do anything just to reach that magical number. Do you really need to test a getter function?
But that's not enough either. A single line of code can be executed in many different contexts, depending on what the state of the system is - choice and ordering of user actions, files existing or not, localization differences, etc. A unit test that executes a line of code for only one situation doesn't go very far to ensure that this line of code will be bug-free when run in a realistic setting. And a single line of code can do a lot of work if it's a call to a system service or an external library API.