> dotnet dotсover test
Important: This post is outdated. Please use the instructions from the dotCover documentation.
If you’ve got the idea of this post just by reading the title, you may skip the next paragraph and go right to the procedure.
We’re going to talk about the
dotCover.exe console runner and a new way to run coverage analysis of unit tests. While the
dotnet tool simplified running tests a long time ago (
dotnet test in the working directory is enough),
dotCover.exe still required you to specify a lot of arguments in order to run tests, like an absolute path to the
dotnet.exe, path to a
.dll with tests, and others. Too much to type, and moreover, there’s no guarantee the paths won’t change at some point. In 2018.2, we came up with a solution: the “dotnet” way to run tests under coverage analysis. All you need is to insert the
dotсover argument to the original string:
dotnet dotсover test
So, this is how you can make it work (steps 1-4 are made only once per project):
- Go to nuget.org and find the dotCover.CommandLineTools package.
- Do NOT reference this package in your unit tests project. Instead, open its .csproj file and add the following line that contains the package name and the current version (2018.2 EAP03 or later):
<DotNetCliToolReference Include="JetBrains.dotCover.CommandLineTools" Version="2018.2.0-eap03" />
- In the command line, go to the directory containing your unit tests project.
This will download dotCover command line tools to your computer.
- Run tests with coverage analysis:
dotnet dotсover test
- The suggested way of using the console runner is NOT a replacement but an addition to the good old dotCover.exe. You can still use it to analyze coverage if you want to.
- If you want to specify any argument you’ve used previously with
dotCover.exe, you can do this by simply adding the
dcprefix to the argument name. E.g., to specify a report type, use
dotnet dotсover test --dcReportType=XML
- You don’t have to specify whether you want to
cover(a coverage snapshot is saved) or
analyze(a human-readable report is saved). This is one more improvement in this release that also applies to
dotCover.exe. Now, the
--dcReportTypeis the only argument you should use: if it is specified, you’ll get a report of a certain type; if not, a regular coverage snapshot will be saved.
- If you configured dotCover.exe via an XML file and want to continue using it, simply specify a path to the file
dotnet dotсover test --dcXML="C:\config\config.xml"
All parameters in the XML file that are not applicable to the new runner will be ignored.
One more important thing: the updated runner doesn’t require any additional workarounds for getting coverage of long-running tests (> 100 ms).
All in all,
dotnet dotсover test is the fastest and easiest way to analyze tests coverage from the command line. It’s already available in ReSharper Ultimate 2018.2 EAP, so why not check it out right now?
Subscribe to Blog updates
Creating Custom AI Prompts
AI has swept through the software development industry like a wildfire. So people want to learn how to best use AI in their day to day tasks. In this post we’ll take a look at how to write custom prompts for use with the JetBrains AI Assistant in ReSharper and Rider so you can make the most of AI.&n…
12 Debugging Techniques In JetBrains Rider You Should Know About
Twelve must know debugging features in JetBrains Rider every developer should know.
Interceptors – Using C# 12 in Rider and ReSharper
Welcome to our series, where we take a closer look at the C# 12 language features and how ReSharper and Rider make it easy for you to adopt them in your codebase. If you haven’t yet, download the latest .NET 8 SDK and update your project files! In this series, we are looking at: Primary …