dotCover 2016.3 Help

Introducing dotCover Console Runner

dotCover console runner is a console application included in the dotCover distribution package. The main tasks of this application are following:

  • Control execution of any test runner (MSTest, NUnit, xUnit, MSpec, etc.) and record coverage of executed tests in coverage snapshots.
  • Merge coverage snapshots.
    You may need to merge snapshots if, for example, you use several different formats of unit tests in your project or solution. In this case, you will have to start console runner for all corresponding test runners and get several coverage snapshots. Then, you can use the merge command to merge the snapshots.
  • Generate coverage reports in different formats.
    Use report command to generate reports in desired formats from coverage snapshots.

In this topic:

Setting up

To set up dotCover Console Runner on a server

  1. Do one of the following:
    • In Visual Studio, go to ReSharper | Options | dotCover | Remote Coverage and click Get Server Package. dotCover will generate an archive with all necessary files.
    • Download dotCover command line tools package from JetBrains website.
  2. Copy the archive to the machine where you are going to set up the Console Runner.
  3. Extract files from the archive to a directory, from which you are going to start the Console Runner executable file (dotCover.exe).

Getting started

Among the Console Runner Commands, the most useful is analyse. It combines all common tasks and generates coverage report as the output.

Configuration of console runner is very simple and can be done via command line parameters or XML configuration files.

The example below illustrates usage of the analyse command:

dotCover analyse config.xml

Where config.xml contains the necessary configuration parameters, e.g:

<?xml version="1.0" encoding="utf-8"?> <AnalyseParams> <TargetExecutable>D:\Program Files\NUnit 2.6\bin\nunit-console.exe</TargetExecutable> <TargetArguments>D:\Projects\TheApplication\bin\Debug\AppTests.dll</TargetArguments> <Output>AppCoverageReport.html</Output> <ReportType>html</ReportType> </AnalyseParams> <Filters> <ExcludeFilters> <FilterEntry> <ClassMask>IntegrationTests</ClassMask> </FilterEntry> </ExcludeFilters> </Filters>

A stub for the config file for each command could be generated automatically by typing

dotCover help analyse config.xml

in the command line. The sample config file would be created with comments indicating what each element means.

Besides test coverage reports, you can get a raw coverage snapshot by using the cover command. You can then open and analyze the snapshot in the standalone dotCover application or in the Visual Studio.

The only limitation of coverage snapshots obtained with the console runner is that they do not contain per-test coverage results, i.e, the following analysis features are unavailable: Viewing Total Coverage of Particular Unit Test Item and Navigation to Covering Tests.

Finding symbol files (PDB)

Locating symbol files (PDB) for the target binaries is vital for calculating coverage. If you cover unit tests or cover the startup project, dotCover easily locates symbol files using the structure of the current solution.

By default, dotCover search symbol files in the following places:

  • in the same directory where the binary file resides;
  • in the debug directory that is specified inside the binary file;
  • in all directories specified in the _NT_SYMBOL_PATH environment variable and in the registry;

If necessary, you can specify other places to look for symbol files. To do so, use the following parameters when using the analyse or cover commands:

  • Use the SymbolSearchPaths parameter to provide a semicolon separated list of paths to search for symbol files. Each path can be either a directory path or a symbol server path (e.g. srv*C:\LocalSymbols*http://symbolserver:33417/).
  • Use the AllowSymbolServerAccess parameter to allow dotCover access symbol servers specified either in the SymbolSearchPaths parameter, or in _NT_SYMBOL_PATH environment variable.

Also in this section

See Also

Last modified: 3 April 2017