Hello.
I have discovered a little problem with code coverage. It seems that, if I write a function that uses a switch statement to test a string and with more than 6 branches, when I write a test for that method, although the test covers all of the code blocks, the code coverage engine shows 1 block as not beeing covered. The code is nicely colored in blue showing I tested all of the branches, but still.
I have tried to use an integer for the switch. It worked without problems.
Aparently, this was a know bug in the Beta 2 of VSTS (http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx feedbackid=33de1b61-19bb-42ac-9283-bd5841534cdd) and was reporded fixed.
I was wondering what happend, and if there is a patch for this or a workaround (except writting if statements instead :D). Maybe a have a wrong version of VSTS :)
Alex
Code Coverage and switch statement don't work well together.
Frederic13
Alex,
You got it. There are a few other locations where things like this happen (such as some foreach loops). We're keeping track of all of these issues and we will be working with the CLR team to resolve this in the best way possible. But for now, there are going to be a few locations were there will be uncovered blocks in areas where you would not expect to see any code uncovered.
Thanks,
Ian
Omns
Aha!
If the line that is not covered is added at compile time and has no match in the source code, then probably there is no test that will cover that, right
Thank you for your answer.
Alex Ghiondea
Apoorva
Was this ever resolved with the CLR team I think I am running into the same problem and was wondering if there is a fix
Thanks
Mehmet Metin Altuntas
AlexRo,
Yes, this issue with the switch statements is still present in the RTM version of Visual Studio. What is happening is that the CLR generates some extra code under the covers that is used for switch statements. The code coverage tool is not lying to you, there actually is an uncovered block of IL in your code, it just won't show up on a specific source line. We're currently working with the CLR team to resolve this for future releases. I'm not sure why that previous ladybug was marked as fixed, but it appears to have been marked in error.
Thanks,
Ian Huff