Monkey see, monkey do; occasionally monkey learn.

random posts from a semi-sentient simian

    Search by
    open cover

    The problem with sequence coverage. (part 2)

    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:

    open cover

    The problem with sequence coverage.

    Sequence coverage is probably the simplest coverage metric, the information is packaged in PDB files and can be read using tools likeMono.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

    open cover

    OpenCover Performance Impact (part 2)

    I think I now have a handle on why I was getting the results I earlier reported i.e. OpenCover [] and PartCover [] 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