-
-
Save karenpayneoregon/89ac896a1a935f4e706b937e710ccc96 to your computer and use it in GitHub Desktop.
<PropertyGroup> | |
<PathMap>$([System.IO.Path]::GetFullPath('$(MSBuildThisFileDirectory)'))=./</PathMap> | |
</PropertyGroup> |
When you say test coverage instrumentation can provide more details?
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.
Hello, @karenpayneoregon :
I have seen this tip on Twitter when you posted about it recently and today I decided to test it.
But adding this configuration broke my test coverage instrumentation. Have you heard anything about this and know any workaround? I liked the idea of reduced source path but I was surprised by this side effect.
Thanks for sharing your knowledge! ;)