NOTE: In VS/TFS 2012 unit testing is based on an extensible system, it is no longer limited to only supporting MSTest as in previous versions of Visual Studio. If the nUnit adapter is downloaded from Visual Studio Gallery then nUnit tests can be included within a solution and build without the need for this custom activity.

Using the new test adapters should be the preferred option instead of this activity.

See the ALM Rangers Build Customization Guide for details in using the new test framework adaptors

The nUnit activity can be used to run nUnit based unit test and publish their results to TFS such they appears in the same reports as MStest based unit tests. In this example we aim to show the the basic steps that are required to get the activity integrated into a build.

Before you can make use of any of the TFS 2010 community build activities you have to make sure they are available for the build system and on your development PC. Instructions for this process can be found in the ALM Rangers build guide or in the StyleCop page of this wiki. This page assumes the nUnit is available in the developers build process workflow toolbox. Hence we are able to build the workflow shown below


Step 1 – Finding test assemblies

The first step is find the MSTest section in your build process, it reasonable to put the nUnit tests at the end of the existing “Try Run Tests” section. This simple integration simply runs the nUnit tests, it make no attempt to modify any flow based on the test results. In the chosen location add a FindMachingFiles activity (from the Team Foundation Build Activities tab in the toolbox). In the workflow above it has the display DisplayName of “Find files containing nUnit tests”. As the name suggests this activity is used to find all the assemblies that could potentially contain tests by scanning the BinariesDirectory and below for assemblies ending in *.Tests.dll.

The result of this find is stored in a workflow variable FilesContainingTests. This should to be created with a type of IEnumerable<string>; it’s scope, in the default workflow, was set to Compile and Test. Once the variable was created the activities output can be assigned to it


Step 2 – Running the nUnit tests

The nUnit activity runs the nUnit console EXE, produces the results as an XML file which is transformed to the Microsoft TRX format and published to TFS. To manage this the nUnit activity has many properties, but tests can be run with very few set if required. Ones that can be critical Version or ToolPath. If the ToolPath (the directory containing the nUnit console application) is not set the path to the nUnit console is built from the Version. This can be a problem if the program is not installed in the expected default location; hence if can be easier to just specify the whole ToolPath.

You also need to provide a name for the OutputFile and OutputXMLFile so the results can be stored, and to be able to publish the test results to TFS you must specific the Flavour and Platform as well as the PublishTestResults flag. 

One gotta is that, if you have not specifically set these in the build definition (as in graphic below)


and you attempt to use the PlatformConfiguration object to provide the Flavor and Platform (as opposed to hard coded strings) empty strings will be passed into the nUnit activity and the publish will fail with the error

Running C:\Program Files (x86)\NUnit 2.5.10\bin\net-2.0\nunit-console.exe /nologo "C:\Builds\1\MSF Agile\BuildCustomisation\Binaries\ClassLibrary1.Tests.dll" /xml="\\typhoon\drops\BuildCustomisation\BuildCustomisation_20110818.16\outputxmlfile.xml" /out="outputfile.txt"
Processing \\typhoon\drops\BuildCustomisation\BuildCustomisation_20110818.16\outputxmlfile.xml
When publishing test results, both Platform and Flavor must be specified

So the minimum properties for the nUnit activity are as shown below


Running the build

When the build runs you should see in the log that nUnit has been run with the correct command line options


and from the build summary page you can follow the link to see the test details


This is a very basic integration of the nUnit activity into a build. For more details on the other available properties check the nUnit console command line reference

Last edited Dec 10, 2012 at 4:38 PM by rfennell, version 5


2ton May 20, 2013 at 2:42 PM 
Regarding my previous post, I have solved my problem. The problem indeed came from using TFS2010 and VS2012. The problem came when it tried to publish the test results to TFS. The command line it tried to run was: "%VS110COMNTOOLS%\..\IDE\MSTest.exe /publish:"http://...". After a bit of investigation I noticed it was trying to use MSTest.exe from the VS2012 directory NOT the VS2010 directory. I could manually run the command line by changing it to %VS100COMNTOOLS%. To get round this issue I installed VS2012 on the build server. Not my ideal solution but it now works perfectly!

2ton May 20, 2013 at 10:13 AM 
Excellent post Richard (I regularly attend your Black Marble events!). I have managed to follow your post and I have successfully got my nunit tests to run when running my build definition. Unfortunately though my build fails with "Error: The system cannot find the file specified". This seems to happen when it tries to access the outputxmlfile.trx file from the drop folder. The trx file is generated and when i run it in VS it works and I see my test results?? Am I missing something? I'm using TFS210 but connecting to it with VS2012. could this be a problem?

jnus Dec 19, 2012 at 6:47 PM 
I'm having problems using platformconfiguration.platform (and .configuration) in my build definition. Any idea why (vs2010/vs2012 + tfs2010)?

ljrich Oct 8, 2012 at 11:34 AM 
Seconded MsGigabyte's comment. Do I just drag one of the NUnit dlls onto the toolbox? Besides that, gracias Mr Fennell, epic work as ever.

ehuna Sep 27, 2012 at 9:31 PM 
Nice! Thank you for the great overview and detailed steps.

msgigabyte Feb 14, 2012 at 9:48 AM 
In my toolbox I dont see nunit. Nunit is installed on my machine but How to make nUnit available in the developers build process workflow toolbox.