Recently, in a build server forum, a new NCover 4 user was asking how NUnit tests are run during a TeamCity build, because it appeared that the built-in test runner process, ‘JetBrains.TeamCity.PlatformProcessRunner.v4.0.x86.exe’, was not starting.
The forum’s expert replied simply that “NCover 4 is not yet supported by TeamCity.”
This is an unfortunate misunderstanding of the fundamental difference between coverage collection in NCover 3 and NCover 4.
In NCover 3, integration with TeamCity, for example, meant defining a build runner step in the GUI, with specific references to NCover 3 parameters, the path to the NCover Console, the bitness level, etc. These steps were added by the JetBrains team to make integration with NCover 3 easier, but with NCover 4, none of this set up is necessary.
The old way — specifying the NCover 3 path.
As one of our devs likes to say, “NCover 4 stays out of the way,” meaning that NCover doesn’t have to initiate the processes you want to cover, and doesn’t require any special configuration on your build server, whether you’re using TeamCity, Jenkins, or Bamboo.
Currently, profiling NUnit from TeamCity requires that you run nunit-console from your build script. The other methods available from TeamCity, such as the integrated NUnit task, aren’t reliable, because they start the NUnit test runner as a sub-process that the NCover service sometimes cannot detect.
Starting Nunit-console from your build script should trigger nunit-agent to start, and this is usually the process to monitor so that your unit test results are profiled.
The new way — adding the NUnit regex.
We’re working to improve this integration so that you can run TeamCity and NUnit in any configuration you choose, but for now, our recommendation is to run nunit-console directly from the build script.
With NC4, the build platform isn’t the focus — your testing is in the spotlight, where it should be.
If you’re running several projects on your build server that all monitor the same process, then you’ll need the NCover USE command to specify the NC4 project that should run for a given build (more about USE in a future post), but otherwise, just set up a project specifying what test runner to watch, and let NC4 do the rest.
For that matter, the same logic applies to your test runners. You no longer need to worry about whether your favorite unit testing tool is still compatible as new versions of NUnit — and NCover — are released. Unless the name of the test process changes, you don’t have to do a thing to your existing project, it will just keep on working. With NCover 4, integration means, “watch me run”!