Shaun Wilde

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

So how does OpenCover's profiling impact your testing. The best way is to get some figures so that you can judge for yourself. I decided to use OpenCover's own tests and use the timing value produced by Nunit itself; just like I'd expect any user who is trying to determine impact I suppose. I've also added the results from PartCover for comparison. Before I took any numbers I (warmed) the code by running the code several times beforehand. Nunit32Nunit32 (OpenCover)Nunit32 (PartCover)Nunit64Nun