Team City Addin for NUnit

Recently at our Virtual Alt.Net group I ran through getting a basic project up and running within Team City 4.0. During the demonstration we were lucky to have a couple of key insiders from Jet Brains join us in the discussion. During the presentation I was painfully hitting the proverbial brick wall of "fail", namely around getting my NUnit test results integrated into Team City's build reports. To save all of you from having to watch the video and to concisely put this rather simple issue to rest quickly, I have concluded at the bottom of this post steps requiring action to have your NUnit tests integrated within Team City. I would like to thank Yegor Yarko and Eugene Petrenko and all participating attendees who offered their assistance in getting this to work!

In order to integrate the NUnit Test runner, Team City requires a bit of additional configuration and the documentation is not as forthcoming as I would like. Hopefully this post will assist others who want to integrate their testing statistics into their build server's dashboard reporting.

Jet Brains indicates that they provide support for NUnit via an addin. The addin provides on-the-fly test coverage reporting integrated within Team City.
The screen to the left appears as an additional chart located within the Settings tab indicating Test Count.

The screen shot below is indicative proof that test reports are not configured correctly. The build itself however is successful. Notice that there are four tabs displayed, there should be five with a Tab named Tests.







When the NUnit test runner integration is correct the screen will appear as follows:












Click on the Tests tab and you can filter the tests by ignored, successful, failed, or all. Additionally you can view your tests by classes, suites, namespaces/packages, or all. This filtering capability is directly above the listing of tests in the screenshot below.








Configuration Steps

It is important to note that with the ensuing steps integration of the NUnit test runner is supported only from versions 2.4X and higher of NUnit.

• Locate the nunit.console.exe.config file for the version of NUnit that you will be using. In this case I chose to use NUnit 2.4.8. The path to the file is C:\Program Files\NUnit 2.4.8\bin. Add the following XML to the config file save and close the file.
  

• I defined a property for locating the NUnit console runner for version 2.4.8. This is optional of course I just find this a cleaner approach as I can reference this location with less noise later in the build script. Additionally its also worth noting that the version for NUnit's console runner does not have to match the version of NUnit referenced within your project's test assembly.
  

• Copy the dll and pdb files for the Team City Nunit AddIn to the location defined above for the nunintconsole property and place the files within the newly defined directory of addins that is created within this task. Then the tests are executed by NUnit.

The Team City test runner for NUnit will work only for version's 2.4x and higher for NUnit. If anyone has some alternative configuration that has worked for them I would love to hear them.

Tricks for dealing with Assembly changes in DocProject

I have been working with Steve Bohlen of late in evaluating a couple of API documentation engines that are being considered for inclusion with NHibernate's API.  

One issue that was bothering me was how to best deal with detecting assembly changes in a Project. As many of you know NHibernate has a rather extensive API that undergoes many regular changes and additions. DocProject is one tool that is being evaluated to perform the documentation requirements. During the initial project setup a wizard prompt requests you to select your assembly targets for inclusion. These assemblies then appear as reference dependency inside of your DocProject project. So the question that was bothering me was what happens if you create new assemblies? Having to manually added these new assemblies to DocProject would become a nuisance as it would be easy to forget to do this step. 

Stephen suggested the following which worked quite nice!

Step 1

Remove the reference assemblies from DocProject

After removing the dependencies, you need to specify an external location where they can be located by DocProject.  Below this is done within the DocProject Properties window supply we supply the External sources location for the source of the assemblies and the XML documentation files. 

Step 2

Create a post build event that copies the Assemblies to the projects output directory which in this case we have created a folder output target called Help. This folder content is also automatically cleaned and scrubbed by the projects build script during the compile task. We added the following macro command in the Project Properties | Build Events section defining a post-build event.

 

Checking the noted changes caused a fail to the build. We need to automate the creation of the Help folder.

Hence I added a make directory task to my compile target in the project's build script.

Now any assemblies newly added within my projects namespace will be automatically detected for documentation. The post-build task can be tweaked to limit the project assemblies you would like to document.