Reported condition-coverage is too high

[Chris-D-Turk]

Coverlet reports 50% condition-coverage for an if-condition that is only 25% covered.

Environment

• TargetFramework net5.0 (or netcoreapp3.1)
• NUnit 3.13.2
• coverlet.collector 3.1.0

Steps to reproduce

Class under Test

public static class Unit
    {
        public static bool DoSomething(int i1, int i2)
        {
            if (i1 > 0 || i2 > 0)
                return true;
            else 
                return false;
        }
    }

Test class

public class Tests
   {
       [Test]
       public void Test_DoSomething()
       {
           Assert.True(Unit.DoSomething(1, 0));
       }
   }

Generate a coverage report using dotnet test --collect:"XPlat code coverage"

(see attachment for complete code) CodeCoveragePlayground.zip

Expected result

coverage.cobertura.xml <line number="10" hits="1" branch="True" condition-coverage="25% (1/4)"> (Only the i1 > 0 condition is covered)

Actual result

coverage.cobertura.xml <line number="10" hits="1" branch="True" condition-coverage="50% (2/4)">

[Chris-D-Turk]

@MarcoRossignoli Could you have a look at this? Is my expectation wrong? I'm really having trouble to understand how coverlet computes condition-coverage. Seems to be way different than jacoco for example.

[daveMueller]

Sorry I can't reproduce it. I tested on 3.1.0 and 3.1.2. Is there anything in addition we have to think of e.g. Release configuration?

[Chris-D-Turk]

But according to your screenshot you did reproduce it. The condition coverage is 50% (2/4). I would expect 25% (1/4) DoSomething(1, 0) <- covered DoSomething(0, 1) <- not covered DoSomething(0, 0) <- not covered DoSomething(1, 1) <- not covered

When I rewrite this testcase in Java and collect coverage via JaCoCo, I get the expected result. condition-coverage seems to have a different meaning to it. Is this intentional or is it a bug?

[daveMueller]

Sorry for the late response and sorry for not reading your issue more carefully. Indeed coverlet produces here 50% coverage. We calculate the coverage according to the branch points the compiler generates. We can see if they were hit by trackers we inject into the assemblies. In the example there are 2 of the branch points hit and thats why it's 50%.

@MarcoRossignoli Do you have a bit more info here? It's really hard for me to understand the branch points the compiler is generating.

[daveMueller]

@Chris-D-Turk Sorry I'm not much of a help here. I debugged this yesterday and tried to understand our coverage calculation for this case but I didn't fully get it. Could also be that there still is bug.

[Chris-D-Turk]

@daveMueller no problem, I hope you guys find the cause of this issue - confuses me everytime I inspect the coverage of our codebase ;) (sry for the late response - missed the notification)

[github-actions[bot]]

This issue is stale because it has been open for 3 months with no activity.

[stg609]

How is it going? We have a similar question about the branch coverage. The reported branch coverage is 100% while only half is covered actually.

[github-actions[bot]]

This issue is stale because it has been open for 3 months with no activity.