-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confusing switch case coverage #72
Comments
Welcome to the world of compiler implementation details, which makes branch instrumentation and interpretation such fun. Except in cases where the branches are a set of adjacent integers, so the IL switch instruction can be used, C# In this case, the source line
compiles to
which has four two-way choices that offer a chance to exit the sequence point. I suspect that the 8th branch, the one not taken, is for a This is comparatively simple IL; switch statements with non-integer labels can compile into more deeply nested expressions with selection on a hash before more expensive matches on precise values -- see here for one example. |
The branch processing logic here is ultimately derived from OpenCover's algorithms; and the implicit design philosophy of that tool (as stated in several branch-coverage related issues) is to expose all the compiler generated tangle, and leave it to the end-user to decide which branches are actually sane, and which are compiler generated (and which may not even be coverable e.g. for F# inlines or Currently, AltCover amends that behaviour, hiding simple conditional branches that terminate within the same sequence-point (compiler generated housekeeping often does this), and combining branches from IL |
Thanks for the detailed response, have to admit though a lot of it went over my head. I've ended up changing the code to be an if, else if instead. The issue was that in our real code the switch case is in a for loop which before the switch case will continue the loop if the value is null so the branch is impossible to reach. Not sure if this is a bug or just an unavoidable thing but I've updated my repo to show the issue. |
In release v6.2.714, the --visibleBranches option clears the compiler generated clutter from reports to produce what you thought you'd get from a switch statement. from command line
|
That's great thanks, appreciate how quickly you're resolving these issues. I've added the flag to the test step of our pipeline. Feel free to close this. |
Hi,
I've got an issue with some confusing coverage statistics being generated for switch cases. My tests have covered all branches including the default branch however AltCover is still considering there to be a missing branch until I test with null as the value. Here's a screenshot of what the coverage looks like...
I've also created a simple reproduction of the issue in the following repository...
AltCoverSwitchCaseTest
Coverage was generated with the following command...
dotnet test /p:AltCover=true /p:AltCoverSingle=true /p:AltCoverCobertura="Cobertura.xml" /p:AltCoverAssemblyExcludeFilter="xunit|.Test"
Is this a bug? Or if not could you please help clear up why there is a missing branch? As far as I can tell in the case that the value is null it should use the default branch which is already covered?
The text was updated successfully, but these errors were encountered: