Compiler generated classes shown in the coverage result file

[LiangZugeng]

I use coverlet to analyze my .NET Core 2.1 app and it outputs cobertura format, then I use report-generator to convert the result file into HTML format for human reading, it's been using in our project for a while and I still haven't figured out some strange issues.

1. I have a class called BlockController, in the coverage result file I found compiler generated classes shown in parallel with BlockController, see screenshot below. I wonder if coverlet can eliminate those classes and combine the coverage data with the actual BlockController.

2. The method name has something as a suffix, take this EaseSource.AnDa.SMT.Web.Controllers.BlockController/<GetAll>d__2, what's the "d__2"?

3. There is one aggregation level missing in the report, the coverage result of all methods in BlockController should be aggregated to BlockController to show the total coverage of this class, unfortunately this is not done, I guess it's because in the coverage result output file, the method coverage data is put in the element, e.g.

        <class name="EaseSource.AnDa.SMT.Web.Controllers.BlockController/&lt;GetByIds&gt;d__5" filename="Web\Controllers\BlockController.cs" line-rate="1" branch-rate="0.5" complexity="0">
          <methods>
            <method name="MoveNext" signature="()" line-rate="1" branch-rate="0.5">
              <lines>
                <line number="496" hits="1" branch="True" condition-coverage="50% (1/2)">
                  <conditions>
                    <condition number="343" type="jump" coverage="50%" />
                  </conditions>
                </line>
                <line number="497" hits="1" branch="False" />
                <line number="498" hits="1" branch="False" />
                <line number="499" hits="1" branch="False" />
                <line number="500" hits="1" branch="False" />
                <line number="501" hits="1" branch="False" />
                <line number="503" hits="1" branch="False" />
                <line number="504" hits="1" branch="False" />
              </lines>
            </method>
          </methods>
          <lines>
            <line number="496" hits="1" branch="True" condition-coverage="50% (1/2)">
              <conditions>
                <condition number="343" type="jump" coverage="50%" />
              </conditions>
            </line>
            <line number="497" hits="1" branch="False" />
            <line number="498" hits="1" branch="False" />
            <line number="499" hits="1" branch="False" />
            <line number="500" hits="1" branch="False" />
            <line number="501" hits="1" branch="False" />
            <line number="503" hits="1" branch="False" />
            <line number="504" hits="1" branch="False" />
          </lines>
        </class>

The output cobertura file for this class is also attached.
coverage.cobertura.xml.zip

Please advice, thanks.

[LiangZugeng]

May I have some comments here? @tonerdo

[Nysosis]

I've noticed this in my projects too, and seems to be occur everywhere that I'm using async/await tasks.

[petli]

Those classes are generated to build the state engine that implements async/await which is mostly hidden by the .NET tooling but shows up here.

This might be considered a bug in ReportGenerator instead. It seems folding classes are done by each report file parser implementations (I had to fix a bug related to that in the opencover parser). I use ReportGenerator 4.0.0-rc6 to process opencover report files, which correctly folds the classes together. A workaround is thus to try out that format instead.

But perhaps it's more useful to do it at the source (i.e. coverlet)?

[LiangZugeng]

@petli thanks for the answer, and I don't think it's a bug in ReportGenerator, I haven't tried opencover report file and I will give it a try later.

The reason I thought it's not a issue with ReportGenerator is that I spent some time using ildasm to view the IL code of the assembly, it's not coverlet interpreting the IL code wrong, coverlet worked exactly according to the IL, but coverlet missed merging the analysis coverage data of some compiler generated classes for lambda expressions into the original code lines, take the following code for example:

        public async Task<IActionResult> SyncDingtalkUsers()
        {
            Dictionary<string, List<AnDaUser>> result = await accSVC.SyncDTUsersAsync();

            List<AnDaUser> newUsers = result["newUsers"];
            List<AnDaUser> updatedUsers = result["updatedUsers"];
            List<AnDaUser> deletedUsers = result["deletedUsers"];

            List<string> newUserNames = newUsers.Select(u => u.Name).ToList();
            List<string> updatedUserNames = updatedUsers.Select(u => u.Name).ToList();
            List<string> deletedUserNames = deletedUsers.Select(u => u.Name).ToList();

            Dictionary<string, Dictionary<string, List<string>>> roleSyncResult = await accSVC.SyncDTRoleAssignmentAsync();

            JObject syncResult = new JObject();
            syncResult["new"] = JArray.FromObject(newUserNames);
            syncResult["updated"] = JArray.FromObject(updatedUserNames);
            syncResult["deleted"] = JArray.FromObject(deletedUserNames);
            syncResult["roleSyncResult"] = JObject.FromObject(roleSyncResult);

            return Success(syncResult);
        }

.NET core compiler generated two things:

1. a wrapped method on the class called SyncDingtalkUsers which is a sync method, it's used to prepare the parameters and to call the actual code using the compiler generated state machine.
2. a private nested class named d__3 which contains the actual code and wrapped as a state machine to be called by the sync method above.
   

In my case coverlet merged the compiler generated classes for async/await calls with the sync methods, and it reported the classes instead of the methods in the result file, but it just missed merging the compiler generated classes for lambda expressions in the following three lines:

            List<string> newUserNames = newUsers.Select(u => u.Name).ToList();
            List<string> updatedUserNames = updatedUsers.Select(u => u.Name).ToList();
            List<string> deletedUserNames = deletedUsers.Select(u => u.Name).ToList();

For the 3 lambda expressions u => u.Name, the compiler generated three methods in another class:

That's the reason I saw the compiler generated classes in the report.

In the perfect world, I expect coverlet:

1. To merge the async/await compiler generated classes into the wrapped method instead of reporting the classes themselves, so we have a consistent view between the code and the report.
2. All compiler generated lambda expression classes/methods would be merged into their original methods.

[danielpalme]

@LiangZugeng
Please try again with the latest (pre-)release of ReportGenerator:
https://www.nuget.org/packages/ReportGenerator/4.0.0-rc11

I changed the behavior of ReportGenerator. The results of compiler generated classes are now merged into the parent class. E.g.
EaseSource.AnDa.SMT.Web.Controllers.BlockController/<GetAll>d__2 to EaseSource.AnDa.SMT.Web.Controllers.BlockController

[LiangZugeng]

@danielpalme Perfect! The latest pre-release version of ReportGenerator solved the issue. Now both lambda and async/await compiler generated classes are merged with the parent class. Thanks for fixing this.

I happen to notice another thing with the new version which I don't understand. See the screenshot below:

And this one:

It reported "1 of 2 branches are covered", this occured on async EF Core queries and null-conditional calls, any idea why it was reported like this? This seemed not exist with 4.0.0-rc1 version.

[danielpalme]

The results of compiler generated classes are now merged into the parent class, that means that branches from the generated classes are also merged into the parent class.

[LiangZugeng]

@danielpalme I understand the generated classes are merged into the parent class, but it appears to me that the async EF Core queries and null-conditional calls bas?.Id have nothing to do with the generated classes, care to explain more details? Thanks.

[danielpalme]

@LiangZugeng
Can you share your Cobertura file (again) that matches the coverage report?
The sample file in you first message seems to be outdated.

Then I can have look and explain what's going on.

[LiangZugeng]

@danielpalme please see the analysis result file at the bottom. I also attached the refreshed screenshots.

In Update method:

EF Core async queries were reported to be covered for only 1 branch:

And null-conditional class were also reported to be covered for only 1 branch:

coverage.cobertura.xml.zip

[danielpalme]

@LiangZugeng
The coverage report is handled correctly by ReportGenerator.
Here are the corresponding branches for the line 818, 828, 885, 892, 894 and 895:

[MarcoRossignoli]

closed because solved in part on report generator and in part with last update on async/await accounting #549