-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Solution-wide coverage results are saved under random project #76
Comments
@aarndt you can try:
but this will still generate final coverage report under path with random guid. Check: microsoft/vstest#2378 IMO the best way to resolve it is use |
Added more documentation about using |
@jakubch1 thank you for the quick response and helpful example. Much appreciated! This worked well on my windows machine. However, an empty coverage file is generated when I run the command on a M2 ARM64 Macbook (some of our devs work with devcontainers on m1/m2 macs). I attempted this with both x64 and arm64 versions of the Edit: |
Yes, this is not working because macOS arm64 is not supported for dynamic instrumentation. So I recommend to do step back and use:
and then use some scripting to find final coverage report. There is also a way to make
This will make sure that all dlls are statically instrumented before command |
Closing as no work needed here. |
This is in regard to the automatic merging of coverage files when tests are run at the solution-level, as described in https://devblogs.microsoft.com/dotnet/whats-new-in-our-code-coverage-tooling/
I pulled the referenced repo with sample code, and while the project-level coverage files were merged into a single file, the project/folder where the file was saved differed between test runs.
2nd execution
As the results show, the coverage of the first run was saved within the
Calculator.Server.IntegrationTests\TestResults
folder, while the file for the 2nd execution was saved inCalculator.Core.Tests\TestResults
I would expect a solution wide file to be saved in the solution root, or under a
TestResults
folder in the sln root by default. I can still manually merge with thedotnet-coverage
tool, but I was excited at the prospect of not needing the extra steps.I am running dotnet 7.0.203 on Windows 11. I get the same results with and without the
dotnet-coverage
tool installed. I am developing in VS Code, but don't believe that is relevant because all of the code samples are from the command line.The text was updated successfully, but these errors were encountered: