I&#x27;ve been getting into shooting for 100% coverage in critical [1] code lately, and while that may not be to everyone&#x27;s taste, what I&#x27;ve noticed is that I <i>always</i> learn things from at least <i>looking</i> at the coverage. &quot;Oh, I thought I had that covered... that&#x27;s interesting, I thought I had that error simulated but it didn&#x27;t happen after all... oh, look, there&#x27;s no possible way to ever enter those 125 lines of nasty-looking code <i>plink</i>.&quot;<p>Might I also add that I discover errors in the error-handling surprisingly often. Coverage testing goes a long way towards reminding you to check those too. What your code does in error cases is part of the spec.<p>Shooting for 100% may not always be the best use of time, but if you are writing unit tests you should at least look at the line-by-line coverage results. You&#x27;ve already done the hard work of writing the test suite, be sure to reap <i>all</i> the benefits you can.<p>[1]: &quot;critical&quot; is, ahem, a <i>critical</i> word here. I don&#x27;t shoot for 100% on everything, but every even halfway sanely-designed system has a &quot;core&quot;. Total coverage on the core has the dual benefits of assuring the core really does work as intended, and making it possible to refactor the core. It is a very common antipattern for the core to metastasize because without a test suite, all ability to modify it, even to fix bugs, is lost.