The Case Against Relying Solely on Unit Test Coverage

<p>The value of unit test coverage has long been controversial among software engineers. Some argue that it ensures all new code gets properly tested. Others claim that coverage is a meaningless metric that serves as a placebo more than anything.</p> <p>In my opinion, both sides are right.</p> <p>It shouldn&rsquo;t be surprising that just because a unit test covers a piece of code does not guarantee an absence of bugs. Unit tests execute in controlled environments based on the developer&rsquo;s expectations. Unfortunately, a production environment is anything but predictable.</p> <p>Business logic can have multiple complex states that execute the same line of code. If you only test one condition, you aren&rsquo;t thoroughly testing your code, even though the coverage numbers say otherwise.</p> <p>Let&rsquo;s look at an example. Consider this simple function:</p> <pre> fun foo(val x: Int, val y: Int) : Int { var sum = 0 if (x &gt; 10) { result += x } if (y &gt; 10) { result += y } return sum }</pre> <p>There are two conditional statements in this function resulting in four possible states. We can achieve 100% code coverage while only covering one state. Here is a test function showing this.</p> <p><a href="https://betterprogramming.pub/the-case-against-relying-solely-on-unit-test-coverage-1cb3977e38ac">Website</a></p>