&gt; <i>In other words, writing another test for the hot section of your code seems to improve quality on average about as much as writing a test for some rarely run code that you didn&#x27;t bother to test until now.</i><p>I&#x27;m not sure.<p>I&#x27;ve given it some more thought. I think the problem with distinguishing between the two is that &quot;coverage&quot; is defined, so to speak, as an area.<p>Once an LOC is executed by any test, its value ticks over once. It never gets counted again.<p>If instead each LOC execution was summed up independently, each LOC gets a &quot;height&quot; -- the number of times it was exercised in a suite. Then the overall suite gets test coverage <i>volume</i>, rather than test coverage <i>area</i>.<p>Once you track per-LOC volumes, you could start trying to tease out the differences between introducing a test <i>at all</i> and adding another test to critical code.<p>And, I suspect, the correlation between coverage <i>volume</i> and bug yield would be much more robust than area when controlled for number of cases. Because area when controlling for number of cases is ... a rough proxy for test coverage volume.<p>Edit: though with an interesting difference. Coverage area converges to 100%, but coverage volume is effectively unbounded. This would hopefully upset the abuse of coverage as a management metric instead of as a code smell.