> dotnet dotсover test

Alexey Totin

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):

1. Go to nuget.org and find the dotCover.CommandLineTools package.
2. 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" />
3. In the command line, go to the directory containing your unit tests project.
4. Run dotnet restore
   This will download dotCover command line tools to your computer.
5. Run tests with coverage analysis:
   dotnet dotсover test

Important notes:

1. 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.
2. If you want to specify any argument you’ve used previously with dotCover.exe, you can do this by simply adding the dc prefix to the argument name. E.g., to specify a report type, use --dcReportType instead of --ReportType:
   dotnet dotсover test --dcReportType=XML
3. 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 --ReportType / --dcReportType is 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.
4. 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 a monthly digest curated from the .NET Tools blog:

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!