Marko Apfel - Afghanistan/Belgium/Germany

Management, Architecture, Programming, QA, Coach, GIS, EAI

  Home  |   Contact  |   Syndication    |   Login
  187 Posts | 2 Stories | 201 Comments | 4 Trackbacks


Twitter | LinkedIn | Xing


Post Categories



Enterprise Library


SQL Server




Its a good practice to have a common naming schema for test projects, fixture categories and fixture. Especially to configure automatic runs of unit tests is much more easier with this.

For each project we have a correspondending test project which has the same name suffixed with .Test. Other teams uses .Test, .Fixture or .Fixtures.

Fixtures themself have the same name like the to be tested class suffixed with Fixture. Maybe that this is not the best idea, because normally each concern of a class should have an own fixture. So the realtionship between class and fixture is not 1:1 but 1:n.

Often you have the situation, that you wanna have additional tests which are not classic unit tests, but test which makes sense for you or functionally steps which you wanna start from your IDE.
These tests are marked with a special category – i use the term NoContinuousIntegrationTest.

So this looks like:

namespace EsriDE.PipelineManagement.Core.Test
    public class ToolboxConfigurationFixture : PipelineManagementFixtureBase
    {        ..
        public void ReadingToolboxConfigurationWorks()

Common output folder for projects

For using IoC-frameworks is often a good idea to have a common output folder for all builds. This common output folder also offers us the possibility to run tests in only one folder. Our common output folder is a sibling to the source folder.

Content of the VCS

Needless to write that you should include the NUnit stuff in your VCS. In our case the files are located beneath .\build\NUnit

The functional part

Creating a batch to run NUnit console runner

Mostly you need the possibility to run unit test outside your IDE. NUnit offers a GUI and a console runner for this. GUI could be nice for you, console runner is nice for build streps. ;-)

To allow a simple access for the console runner you should create a batch in your source root folder. RunNUnitConsole.bat is a good name for this batch.


IF "%1" == "" (SET Configuration=Debug) ELSE (SET Configuration=%1)
ECHO Configuration=%Configuration%
PUSHD .\..\bin
DEL *.dll.NUnitResult.xml
PUSHD .\..\bin\%Configuration%
FOR %%f IN (*.Test.dll) DO .\..\..\build\Nunit\nunit-console-x86.exe %%f /process=Single /domain=Single /nothread /exclude="NoContinuousIntegrationTest" /xml=.\..\%%f.NUnitResult.xml


The first section we need later for including in Hudson. Parameter %1 and varaible %Configuration% lets distinguish between Debug- and Release-Build. If the batch is called without an argument the Debug-Build is the default build.

Section two cleans former unit test run results.

The realy interesting part is the last section. First we switch in the above explained common output folder – depending on the build-configuration.

Next we interate through all assemblies which names and with .Test.dll and using this assemblies as an input for the nunut console runner (nunit-console-x86.exe).

  • parameters /process=Single /domain=Single /nothread
    Special configuration for our environment.
  • /exclude="NoContinuousIntegrationTest"
    Does not consider tests which are marked as the categorie “NoContinuousIntegrationTest
  • /xml=.\..\%%f.NUnitResult.xml
    Outputs for each test project a XML-based result file – named like the project suffixed with .NUnitResult.xml

Configuring Hudson

Now its the right moment to configure your Hudson job

Run the batch

Add build step to your Hudson job (Execute Windows batch command) with the following command:

PUSHD ".\trunk\src\"
RunNUnitConsole.bat %CONFIGURATION%

The argument %CONFIGURATION% is managed from Hudson.

Configuring Dashboard

The last step is the functionallity to collect the unit test results for Hudsons dashboard.

Maybe you must install a special plugin – i do not remember that.

Activate “Publish NUnit test result report” and specify **/*/*NUnitResult.xml

The next job execution lets run our batch with the nunit console runner over all test assemblies and after that the dashboards shows a statistic with the results.

posted on Wednesday, July 7, 2010 3:41 PM


# re: Integrate NUnit in Hudson CI-server 2/11/2011 1:52 PM Nupur
I am using NUnit plugin in Hudson.Hudson uses Unit Testing.It works just fine but on publishing Test Reports,the Build is failed and it throws an error "No NUnit test report files were found. Configuration error?".Please help me....

# re: Integrate NUnit in Hudson CI-server 9/8/2011 4:43 AM Zhenyu
thanks a lot for these steps, it helped me a lot.

But, after sending out the report, I only see "All tests passed",
so, is it possible for everyone know that the high level info, like "how many cases are running" "how many cases failed and passed" ?


# re: Integrate NUnit in Hudson CI-server 9/8/2011 8:30 AM Zhenyu
I have checked the content token reference in Hudson , it seems that only ${FAILED_TESTS}, this parameter show the failed unit result about testing. according this parameter name, will it only display the failure case ?
I just want to retrieve all the cases including success and failed case.

Post A Comment