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’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’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’t thoroughly testing your code, even though the coverage numbers say otherwise.</p>
<p>Let’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 > 10) {
result += x
}
if (y > 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>