Monkey see, monkey do; occasionally monkey learn.

random posts from a semi-sentient simian

    Search by
    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 [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

    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 [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

    open cover

    OpenCover Performance Impact

    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