Shaun Wilde

Previously I mentioned why just relying on sequence coverage is not a good idea as it is possible to have 100% sequence coverage but not 100% code coverage. However I only described a scenario that used a branch that had 2 paths i.e. the most common form of the conditional branches, but there is one other member of the conditional branch family that exists in IL and that is the switch instruction; this instruction can have many paths. This time I am using the code from the Newtonsoft.Json [http:

Sequence coverage is probably the simplest coverage metric, the information is packaged in PDB files and can be read using tools likeMono.Cecil [http://www.mono-project.com/Cecil], but just because a method has 100% sequence coverage does not mean you have 100% code coverage. I'll use an example from OpenCover's own dogfood tests to demonstrate what I mean. Here is a method which shows that it has 100% coverage (sequence point that is). However I see an issue and that is that on line 101 the

I think I now have a handle on why I was getting the results I earlier reported i.e. OpenCover [https://github.com/sawilde/opencover] and PartCover [https://github.com/sawilde/partcover.net4] were not some magical performance boosters that added Go Faster stripes to your code. After a heads up by leppie and his investigations of using OpenCover on his IronScheme project I realised that I needed to spend some time on optimizing how I get data from the profiler and aggregate it into the report. I