Getting Started with NUnit
This tutorial aims at describing the basic practices of using NUnit 3 in TeamCity. The test project and script samples can be found here. The order of use cases is based on the number of the TeamCity features involved: the first case is the most basic, more complex cases that follow utilize a larger number of features. We recommend you familiarizing yourself with all features, finding their advantages and disadvantages, and then decide in favor of one or another.
Installing NUnit
To use the TeamCity NUnit build runner, install the NUnit NuGet package on TeamCity agents first using one of the following options:
Add the NuGet Install build step as the first step of your build configuration.
For example, you can add a Command Line build step before the NUnit build step which will install theNUnit.ConsoleNuGet package as follows:%teamcity.tool.NuGet.CommandLine.DEFAULT%\tools\nuget.exe install NUnit.Console -version 3.6.0 -o packagesNote that
%teamcity.tool.NuGet.CommandLine.DEFAULT%is a reference to the NuGet installed under the TeamCity agent.
You can install NuGet on agents from the Administration | Tools page, where you can also mark one of the installed NuGet versions as default.After that, the
%teamcity.tool.NuGet.CommandLine.DEFAULT%parameter reference should properly resolve to the NuGet installation path on the agent.
Then nunit3-console should appear under the packages directory.To run tests, in the next NUnit build step specify the NUnit path in the NUnit settings as
packages\NUnit.ConsoleRunner.3.6.0\tools\nunit3-console.exe.or
Install NUnit manually on all the agents in some standard location and configure the path to
nunit-console.exein your NUnit build step.
Case 1. Command Line
Starting from version 3, NUnit supports TeamCity out-of-the-box, which allows running tests from the command line, preserving the basic features TeamCity-NUnit integration. NUnit automatically detects if it is run by TeamCity and, if so, switches to the integration mode.
In addition to auto-detection, the NUnit 3 console handles the special --teamcity argument, which also includes the integration with TeamCity. This argument can be used for the purposes of debugging, when you need to see what information NUnit sends to TeamCity: detailed test information, the order of tests, and so on.
Using the NUnit console from the command line is the simplest way to run tests. TeamCity provides the following basic features of integration for the command line:
reporting the test run information in Build Log while the tests are executing
reporting the test results upon the tests finish
all the TeamCity investigation features
This is what the TeamCity build step to run tests from the command line looks like:
To sum up, with this simple case you can use the basic features of the TeamCity-NUnit 3 integration.
Case 2. MSBuild
This use case is very similar to the previous one, but it aims at MSBuild which is the most widely used build platform for .NET projects.
TeamCity supports collecting code coverage statistics out of the box; additional plugins can be installed to use the JetBrains dotTrace and JetBrains dotMemory Unit in TeamCity.
The project file is trivial: the Exec task, which launches tests, is run:
The NUnit console returns the number of failed tests as the positive exit code and, in case of the NUnit test infrastructure failure, as the negative exit code.
TeamCity controls the test execution progress, but the NUnit infrastructure exceptions may not allow TeamCity to collect the required information. That is why the IgnoreExitCode="True" attribute needs to be set, which will ignore the positive exit codes and will not interrupt the build due to several failed tests. The Error task will stop the build in case of the test infrastructure errors for the negative exit codes.
Besides the project file, you can define the MSBuild version and target platform, use profiles and other settings.
To make the build more stable, you can introduce a few changes to the project file. For example, you can define the path to the NUnit console dynamically. This path may change with the updates of the NUnit console NuGet package, but our build configuration will not require any changes. The code below gets the path to the NUnit console to the pathToNUnitConsole variable:
You can dynamically list the assemblies to be tested. For example, search for them in specific directories and filter them to match a regular expression pattern:
The following project files contain some examples: sample2adv.proj, unit-utils.targets.
Case 3. NUnit Build Step
Note that the NUnit runner supports only .NET Framework. To run tests for .NET Core projects (and .NET Framework projects version 4.0 or later), use the .NET build runner with the test command instead. Refer to the NUnit Support page for details.
The NUnit build step is probably the simplest and yet most powerful way to launch NUnit tests in TeamCity.
In most cases its sufficient to set only the 2 parameters: the path to the NUnit console runner and the list of assemblies to be tested.
The NUnit runner field defines the NUnit version used to run tests. When configuring your build step for NUnit 3, the Path to NUnit console runner field is required to contain the path to the NUnit console: specify the path to the console executable file including the file name.
In all the examples the NuGet package manager provides the NUnit infrastructure. Using NuGet enables the user to conveniently manage the test environment, update NUnit, and run test locally as they will be run by TeamCity.
The NUnit build step is a straightforward and user-friendly way to run NUnit tests in TeamCity. It provides the maximum range of options simultaneously concealing the specifics of running tests on different OSs by using Mono.
Case 4. NUnit Build Step, options
When configuring the NUnit build step for NUnit 3, it requires specifying the NUnit Console runner (either selecting a preinstalled tool or entering a custom path).
The other fields provide a lot of useful options, and this section discusses some of them.
One of the options is defining the application configuration file. Sometimes tests obtain data from a configuration file, and to facilitate this, you need to define the path to the application configuration file to be used when running tests in the Path to application configuration file field. The path can be absolute or relative to the Build Checkout Directory. Unfortunately, NUnit is limited by allowing only one configuration file per build step. Due to this limitation, if you need to test several assemblies with different configurations in one build step, you have to aggregate several application configuration files into a common configuration file. If it is not possible, split the test launch into several steps and define a configuration file in each of the steps.
The NUnit 3 console has a great number of settings defined by command line arguments. The Additional command line parameters field allows setting many of the command line parameters for the NUnit console, but there are some limitations:
The
--wherecommand line argument is used as the priority test filtering setting. When it is used simultaneously with the NUnit categories include or/and NUnit categories exclude fields to filter tests by category, TeamCity will ignore these options: a warning will be displayed and only the--whereargument will be used.- Using the parameters below in the Additional command line parameters field may cause your build to fail:
the list of assemblies to be tested, as the NUnit build step determines the list of assemblies from the NUnit project file due to the command line size limitations
NUnit project file, as TeamCity creates its own temporary NUnit project file (see below)
--work: the NUnit build step uses the Build Checkout Directory as the base directory--noheaderis used by default--x86if the .NET Runtime | Platform field is set tox86--frameworkif the .NET Runtime | Version is set to something other thanauto--exploreif the algorithm below is used
The NUnit build step can be set to first run the tests which failed in the previous builds. The idea is that it saves time to conclude about a probable state of the finished build. If the Reduce test failure feedback time flag is set, the tests are run in three steps provided that the previous build has failed tests:
1. As the first step, TeamCity obtains all the list of tests for assemblies taking into account filters by category (the --explore console argument is used), the statistics of the previous step run is analysed and 2 test lists are created: the priority list and the rest. The priority list includes the tests which failed in the previous build.
2. During this step the priority tests are run.
3. The remaining tests follow.
Another great feature of the NUnit build step is the fact that it executes tests on different OSs the same way, without changing the configuration. This is true if the agents, where the full-blown .NET is unavailable, have Mono. It allows the build configurations to be OS-independent.
Debugging NUnit tests
All the actions performed by TeamCity to run tests a user can reproduce in the command line. This allows for quick and effective resolution of the potential issues with configuring a build.
TeamCity records all the data related to running tests into the build log. Thus, the commands that TeamCity uses to run tests can be copied from the build log and can be run from the command line locally or on agents.
When running tests, besides commands, TeamCity creates temporary files:
NUnit project files
JetBrains dotCover
JetBrains dotTrace or JetBrains dotMemory Unit configuration files
These are contained in hidden build artifacts. For example, the command line launching tests for case 4 will look as follows in the build log:
In this case 5Oqkbf9J2qJNkUK4KEtKvxs8TFFnlrno.nunit is the NUnit project file, which can be downloaded from hidden build artifacts:
