Running NUnit Tests in TFS 2010 Continuous Build Environment

Posted by I'm in o-HI-o on February 1, 2011

Microsoft Team Foundation Server 2010 does not provide an easy way to run NUnit test as part of the continuous integration process. Some pretty intense work goes into running those unit tests, and even more is required if build success should depend on unit test success.

Download: NUnit Test Execution Action Section

Strategy:

The build strategy should be implemented in a Build Process Template. The strategy incorporates input from the Build Definition. For example, if the Build Definition notes that test should not be run, then the test assemblies will not be exercised by NUnit.

Disable tests

If the build is set to fail on failed tests, then the entire build will be failed if there are ''any'' test errors or failures.

If the build is not set to fail on test failure and there are failed tests, then the build will be considered partially successful.

Fail test on build

Build Success Indicators

Failed tests that cause build failure are Build Exceptions on the Build Summary page.
Build Errors

Failed tests that do not cause build failure a Build Warnings on the Build Summary page.
Build Warnings

Detailed output for failed tests can be viewed on the "View Log" link on the Build Summary page.

View Log Link

Following are some highlighted steps that are necessary as part of the process to exercise the NUnit tests in TFS 2010.

1) Determine the test assemblies based on the Test Assembly Wildcard Selector specified in the Build Process Parameters.

The Test Assembly Filespec parameter is used to determine which solution assemblies should be processed by NUnit. This can be modified based on a specific project's needs.

Test Assembly Filter

2) Execute the NUnit tests on each test assembly

Execute NUnit workflow action

The nunit-console application is called on each test assembly.

nunit-console.exe <assembly path> /xml:<result target path> /nologo /nodots

3) Take appropriate action for failed tests

The existence of failed tests is determined by parsing the output generated by executing the tests. This output is stored in a local variable.

Handle Failed Test Workflow Action

The test is considered failed the following condition is met.

(Not stdOutput.Contains("Failures: 0") And stdOutput.Contains("Failures:")) Or (Not stdOutput.Contains("Errors: 0") And stdOutput.Contains("Errors:"))
Where stdOutput is the output generated from the executed tests.

'''When there is a failing test'''

  • the Build Detail Test Status is put into a failed state.
  • if "Treat Test Failures as Build Failures" is selected, then a Build Error is generated
  • if "Treat Test Failures as Build Failures" is not selected, then a Build Warning is generated
  • </ul>

    Using:


    Executing the NUnit tests requires reworking the default "If Not DisableTests" workflow step in the build process template. Build process templates are XAML files. They can be edited in the workflow editor in Visual Studio 2010 or in a text editor. If modified in a text editor, care should be taken to ensure the final product is a valid TFS TeamBuild Workflow XAML file.

    To add the NUnit test runner to the default build process template (Download Here), If Control Flow section with the XAML from the attached file.

    If Not Disable Tests

    To use the new build process definition template that has implemented the NUnit test runner, a new build process should be created and the new template should be used.

    Select Build Process Template

    All builds now executed will execute the NUnit tests in place of the standard MSTest test suite.

    Download: [NUnit Test Execution Action Section]