-
-
Save karenpayneoregon/89ac896a1a935f4e706b937e710ccc96 to your computer and use it in GitHub Desktop.
<PropertyGroup> | |
<PathMap>$([System.IO.Path]::GetFullPath('$(MSBuildThisFileDirectory)'))=./</PathMap> | |
</PropertyGroup> |
Sure!
When running tests, I use xUnit and coverlet.msbuild / coverlet.collector to calculate the code coverage and later I use ReportGenerator tool to generate a nice HTML report.
After I adopted in my projects - to test your idea that I found very useful - the PathMap configuration, calculation of code coverage presented a bug.
This is the bug during code coverage calculation - I assume changing paths also affected the way coverlet.msbuild interacted with build artifacts.
This is the normal code coverage calculation.
And I run tests through tasks in VS Code, chained with other tasks to generate code coverage report, but the command in the end is (full project path were ommited since it is a closed source project):
dotnet.exe test Tests\Tests.csproj -v:Minimal -c:Debug -p:CollectCoverage=true -p:CoverletOutputFormat=opencover -p:CoverletOutput=Tests\coverage.opencover.xml -p:ThresholdType=Branch -p:Threshold=70 --no-build
When I made the changes I mentioned previously, I got the benefit of reduced short path with the additional benefit of having correct code coverage calculation using coverlet.
@karenpayneoregon : if you need further info, please let me know. The project in question is closed source but I can try to spin up a minimal one in my GitHub repo if necessary.
When you say test coverage instrumentation can provide more details?