JetBrains dotCover
TeamCity comes bundled with the console runner of JetBrains dotCover. Since TeamCity 2017.1, in addition to the bundled version, it is possible to install another version of JetBrains dotCover Command Line Tools and/or change the defaults using the Administration | Tools page. After choosing the appropriate option in the .Net coverage section of a build step, you will be able to collect code coverage for your .Net project and then view the coverage statistics and detailed coverage report inside the TeamCity web UI.
If you have a license for dotCover and have it installed on a developer machine, TeamCity-collected coverage results can be downloaded and viewed inside Visual Studio with the help of the TeamCity Visual Studio Add-in.
dotCover Settings
Path to dotCover Home | Leave this field blank to use the default dotCover. The bundled version is set as default prior to TeamCity 2017.1; after this version you can mark any of the additionally installedversions as default. Alternatively, specify the path to the dotCover installed on a build agent. |
|---|---|
Filters | Specify a new-line separated list of filters for code coverage. Use the For example, to run coverage on all MyDemoApp assemblies but not on MyDemoApp.*.Tests, specify the following assembly filters for coverage: See also this blog post. |
Attribute Filters | If you do not want to know the coverage data solution-wide, you can exclude the code marked with an attribute (for example, with |
Additional dotCover.exe arguments | Provide a new-line separated list of additional commandline parameters to pass to dotCover.exe |
Note that dotCover coverage engine reports statement coverage instead of line coverage.
Compile and Test in Different Builds
To build a consistent coverage report, dotCover has to be able to find source files under the build checkout directory which should be easy if you build binaries and collect coverage in the same build, or if you use different builds, but they use a snapshot dependency and the same agent as well as the same VCS settings.
If you need to build binaries in one build and collect code coverage in another one using different checkout settings, some additional properties are required. It is assumed that:
Build configuration A compiles code with debugging information and creates an artifact with assemblies and
.pdbfilesBuild configuration B runs tests with dotCover enabled and has a snapshot dependency on A.
To display the source code in the Code Coverage tab of build results of B, you need to point B to the same VCS root as A to get your source code in an appropriate location (the checkout root) and add an artifact dependency on build from the same chain of A (for dotCover to get the paths to the sources from the .pdb files).
You also need to tell TeamCity where to find the source code. To do this, perform the following:
Add the
teamcity.dotCover.sourceBaseconfiguration parameter with the value%\teamcity.build.checkoutDir%to the compiling build configuration A.Add the configuration parameter
dotNetCoverage.dotCover.source.mappingto your test configuration B with the value%\dep.btA.teamcity.dotCover.sourceBase%=>%\teamcity.build.checkoutDir%, wherebtAis the actual id of your configuration A.
Bundled dotCover Versions
This section provides information on the versions of dotCover bundled with TeamCity 10+ versions. For information on the earlier TeamCity releases, see the previous documentation version.
TeamCity Version | dotCover Version |
|---|---|
TeamCity 2017.2 | dotCover 2017.2.2 |
TeamCity 2017.1.5 | dotCover 2017.2 |
TeamCity 2017.1.1 | dotCover 2017.1.1 |
TeamCity 10.0.3 | dotCover 2016.2.2 |
TeamCity 10.0.2 | dotCover 2016.2 |
TeamCity 10.0 | dotCover 2016.1.2 |
Since TeamCity 2017.1, you can view the installed versions of dotCover on the Server Administration | Tools page. The bundled version is set as default, you can install other versions and change the default settings.