Some of us are sticklers for detail. For now the names will be withheld to protect the nearly innocent, but suffice it to say that we do have teams out there who relentlessly pursue 100% BP and SP coverage. And if we’re all honest, we take pride in seeing that number hit 100% for a given method under our scrutiny. This effort can be puzzling at times because what our code shows us isn’t usually the full story of what the machine is seeing. In an effort to assist and calm our most valiant of testers, I offer this nugget of advice concerning the ubiquitous switch statement.
The Switch statement generates specific IL which by definition has a branch to handle the “default” value, or rather any value that is not explicitly covered by a “case” statement. The common issue encountered by teams is that a switch operating on an enum type very often does not express a “default” clause and therefore this branch for the default goes unspecified and uncovered, but that doesn’t make it go away. This practice creates an apparent discrepancy in coverage data. Under this circumstance all sequence points can be executed and this unspecified yet invisible branch goes unvisited in our code. Since no default clause is specified there is no real estate for NCover to mark as uncovered. NCover dutifully and annoyingly reports 1 branch uncovered.
By now you must agree that NCover correctly reports that we have not tested the Switch 100% if we have not supplied at least one value which that switch statement does not explicitly expect. It’s not necessary to explicitly define a default clause to achieve 100% coverage, but having a default clause will help make that missing branch visible. Best practices concerning switch statements should be considered in these coding efforts. Some strongly recommend that the default clause be included to throw an exception in expectation of future changes which the current cases don’t handle. Whatever the coding standard, understanding the code behind the code is essential to achieving that 100% coverage perfection.
Below is a simple illustration that highlights the discrepancy caused in this switch statement scenario. In the sample the numeric difference is no small matter. One branch point means a nearly 10 point swing in the coverage percentage, from 90.9% to 100% coverage. So having divulged the moral of this story in prior paragraphs, it boils down to this: the key to getting 100% branch coverage on a switch statement is to make sure that switch statement is tested with at least one value that has no matching case clause.
Coverage discrepancy between BP and SP with uncovered branch in switch
A switch statement not tested with an unknown value can hide a branch point
Adding a default clause makes the branch visible whether covered or uncovered
Covering the branch is as simple as testing for an unexpected value “unknown”
Resulting in that elusive 100%
For more assistance with .net code coverage with NCover contact our support & integration specialists.