Reportgenerator: Question about the metrics table in the html report when merging several coverage.xml files

[adu89]

I have 3 projects:

Project A (A web api)
Project B (Unit tests for Project A)
Project C (Integration Tests for Project A)

Project B and C may test the same methods inside of Project A.

When i produce a merged report (of the individual coverage.xml files produced), the metrics table sometimes lists the methods of a given class multiple times:

I have a couple of questions:

1. Is there no way to combine (or use the max value) the given metrics (Cyclomatic complexity, NPath Complexity, etc) for a given method so that the method only appears once in this table?

2. Why would the same method have a different Cyclomatic complexities in this case? Is the calculation of the cyclomatic complexity dependent on the test that is being run?

I apologize in advance if the answers to these questions are trivial!

[danielpalme]

Will have look at your questions within the next 1-2 days.

[danielpalme]

Regarding question 1.

That's really strange, method names should appear only once. Can you please share the coverage.xml files.

Regarding question 2.

Also strange. ReportGenerator is not calculating the cyclomatic complexity itself, it just shows the values from the coverage.xml file.

[danielpalme]

I looked at your coverage files.
The two files seem to be generated from different versions of your code.

The methods do not start in the same line and therefore they get listed twice.
E.g. CreatePitch() starts in line 31 in the first file and in line 32 in the second file.

You should only use coverage files created from the same source code, then merging will work just fine.

[adu89]

@danielpalme thank you for the quick reply. This is interesting. Although the tests are run on the same code base, the setups are different. One test run is done on the host process (same process that generates the report). The integration tests are done in a docker environment that simulates our production environment (with external dependancies). Will take a deeper look to see if doing things this way is causing the line difference.

Thanks again.

[adu89]

@danielpalme For sake of completeness...

I ended up figuring it out. The issue ended up being an oversight on my end. The two instances of dotnet test where each being run with different build configurations!

Once again, thank you!