Normalize File Paths In Generated Reports (Linux / Windows)

[abbotware]

I run unit tests on windows and linux. This produces coverage report files that have different path roots:

C:\src\build\file.cs
vs
\var\src\build\file.cs

When the reports are merged it thinks there are 2 sets of functions. Instead of 100% code coverage, i have 50% coverage.

Perhaps a new command line option is needed to normalize the path:

coverlet -stripFromPath=C:\src\
coverlet -stripFromPath=\var\

That way both reports will then have a normalized file

[MarcoRossignoli]

Which format are you using?Which reporter?
Let me understand your scenario, why you have to merge two coverage from two different plat?
I mean if you've some code that run on win and other that run on unix system you could filter out files with ExcludeByFile filter.

[abbotware]

Cobetrua format. The msbuild integration tasks.

I write software that has to work on different platforms. There are subtle differences in behavior on different OS platforms and I have caught some bugs by just running the same code on different platforms. Sometimes this is known ahead of time, other times it is not - so I can't filter by linux /
windows.

Even if I did it would be the same function with different code branches... and hence I would want to see the merged result of coverage between linux and windows

[abbotware]

Also from reading more of the Docs.. it looks like if I was using SourceLink (I am not using git so I can't) it might resolve the paths to the same file and this would not be an issue.

so in my case, I think there are 2 options:

1. make the report merger smarter (ie use namespace / class / function to align code)
2. normalize the file names in the reports (I think this is the easier option)

however if you know any other way please let me know!

Also I am more than happy to make an attempt via a branch / PR for option 2 as it looks like it would just be some new option that is used to normalize the files before any processing really begins.

[MarcoRossignoli]

With #614 in next version you could only update "sources" is you've same relative path for cs.

Also I am more than happy to make an attempt via a branch / PR for option 2 as it looks like it would just be some new option that is used to normalize the files before any processing really begins.

I don't know...seem very specific to your use case, I mean you've "same" relative path until root, there are tons of other scenario where this rule don't work.
For now if you know well your report you could simply create a script that renames fragment how you want before generate reports.

[abbotware]

so then your saying you don't support coverage reports on linux and windows at the same time - The paths will never be the same since they use a different convention.

[abbotware]

But you are right about the pre-processing script... I can do an xslt or regex replacement easy enough :-)

[abbotware]

so upon doing this, the counts seem wrong - each code block is only hit 1 time even though I know each unit test was run twice! (linux and windows)

Other problems:

• the mainreport says 100% code / 50% branch - but the drill down says 100% for both
• the branch covered icon has the green / red indicator meaning that a branch was not covered

Editing the paths in the report is effectively the same thing as if I were to add the option I was suggesting, so I think these issues are more internal.

[MarcoRossignoli]

so then your saying you don't support coverage reports on linux and windows at the same time

At same time no...it's first time I see a this request, but it's interesting, usually this is stuff for "post report production" related to report viewers.

Other problems:

Can you provide a repro?Or provide the "json" version of report?Json version is the "raw" version that we can use to troubleshoot.

[abbotware]

oh wait a minute - while yes I originally requested the cmd line option in coverlet to produce normalized files... the report is being merged by dotnet-reportgenerator-cli ... so those are not problems for you :-)

[MarcoRossignoli]

@abbotware feel free to close this issue if solved from our side.

[abbotware]

@MarcoRossignoli - it appears that the output files have different branch data for the same lines of code - so when merged the counts are incorrect.

@danielpalme discovered the inconsistency when I sent him the raw input files for analysis

in one case 1/1 branches are covered... in another case 0/2 branches are covered - for the same exact line of code!

[abbotware]

I have a unit test and integration test stage - the unit tests are 'safe' to run at all times.. the integration tests may have side effects and interact with 3rd party systems...

It would make sense that in one coverage report (the unit tests) there would be some code that is never executed (the 0/2 branch) while the integration test will execute that code (the 1/1 branch)

why the branch counts are different seems to be the issue