Exciting news for developers! We’ve enhanced our code coverage tools, Microsoft.CodeCoverage and dotnet-coverage, with some fantastic features. If you’re new to our tools, check out our Get Started guide. Let’s dive into the changes that will simplify your coding experience.
Support for All Platforms
Our tools can run on any platform supported by .NET, thanks to the addition of static instrumentation. Learn more about static and dynamic instrumentation, and discover supported platforms.
Fresh Report Formats
We’ve revamped our code coverage report formats to integrate smoothly with tools like ReportGenerator. While the default remains the familiar .coverage format, we’ve introduced some new ones:
- Binary (Default): .coverage (Microsoft’s special format) – Open it in Visual Studio Enterprise. Example
- Cobertura: .cobertura.xml (Open-source XML format) – Open it in Visual Studio Enterprise, any text editor, or generate an HTML report with ReportGenerator. Example
- XML: .xml (Microsoft’s XML Format) – Open it in Visual Studio Enterprise and any text editor. Example
Meet dotnet-coverage
Introducing our new tool, dotnet-coverage! It performs following tasks:
- Collects code coverage for console applications. Example
- Collects code coverage for web applications. Example
- Merges coverage reports. Example
- Instruments binaries. Example
- Calculates code coverage for each test separately. Example
Visit dotnet-coverage documentation to learn more.
Auto-Merge for solutions
Running dotnet test --collect "Code Coverage" at the solution level now automatically merges code coverage for all your test projects. Visit Scenario 24 Code coverage for solution to see full example.
Improved Documentation
Explore our fresh GitHub repository at microsoft/codecoverage for all the info and samples you need.
Faster Performance
Prior to the 16.5 release, the collection of code coverage report significantly slowed down test execution. We addressed this issue, resulting in an impressive 80% performance gain. See performance section for detailed results and logs.
| Package | Time | Ratio |
|---|---|---|
| Microsoft.CodeCoverage 16.5 | 03:52:53 | 1.00 |
| Microsoft.CodeCoverage 17.0 | 02:25:49 | 0.63 |
| Microsoft.CodeCoverage 17.5 | 01:27:52 | 0.38 |
| Microsoft.CodeCoverage 17.9 | 00:50:00 | 0.21 |
What You Need to Do
To enjoy the latest features and speed up your builds, make sure to use our latest stable packages in your test projects:
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.8.0" />
<PackageReference Include="Microsoft.CodeCoverage" Version="17.8.0" />If your solution doesn’t have any C++ code, make it faster and more reliable by turning off native code coverage with these flags in runsettings:
<EnableStaticNativeInstrumentation>False</EnableStaticNativeInstrumentation>
<EnableDynamicNativeInstrumentation>False</EnableDynamicNativeInstrumentation>Visit configuration documenation to see other options and full example of our settings.
Special Thanks
A big thank you to Faisal Hafeez, Marco Rossignoli, Mariam Abdullah, Codrin-Victor Poienaru and Pavel Horak for their exceptional contributions to this project! 🙌🚀
This looks really great.
But something that confuses me a lot is when do I need
dotnet-coverage collectand when isdotnet test --collectenough?In some samples both are used in others not. Unfortunately it’s not clear to me.
And since
Microsoft.CodeCoverageis a dependency ofMicrosoft.NET.Test.Sdk, there is no need to explicitly referenceMicrosoft.CodeCoveragefor test assemblies, since it is already referenced transitively?collects code coverage for any managed tree of processes (ASP.NET server, console application). is specific for test projects and runs tests with code coverage collector enabled. Generally using is enough in most scenarios and it is recommended.
If your test project communicates with external service which is started before test execution, then to get code coverage for external service you have to use tool. This scenario you can find here: https://github.com/microsoft/codecoverage/blob/main/samples/Calculator/scenarios/scenario14/README.md
I understand your confusion here as running tests () is also managed process so you can do: and the result is equivalent to . Command...
What happens when you run
and the unit test project starts (and gracefully terminates) the server (as a child process)? Will Microsoft.CodeCoverage collect the code coverage of the server (child) process? coverlet does this if (and only if) the server (child) process is properly terminated.
Microsoft.CodeCoverage and dotnet-coverage tools collect code coverage for all child processes. Additionally coverage data is passed through shared memory and coverage is collected even if child process crashes. We don’t store any information on termination. Example is here: https://github.com/microsoft/codecoverage/blob/main/samples/Calculator/scenarios/scenario11/README.md