Using NUnit with Visual Studio 2005

This article describes how to use NUnit with Visual Studio 2005. In particular, I am using Visual Studio 2005 v 8.50727, which is similar to release candidate 1. This is a solid build of Visual Studio, but NUnit needs to be reconfigured to work with it smoothly. The solution to this problem is simple and fairly well known by this time, but I thought I would spell it out here, just so I would have an easily accessible written record of it.

I had the best luck with the most recent version of NUnit, which at this time is 2.2.2. This is called an iteration release, and it is dated Dec 7, 2004. Don’t confuse this release of NUnit with version 2.2.0, which was released on August 8, 2004.

Here is lightly edited a note from the NUnit web site: Iteration releases are works in progress. They are subject to change as we receive feedback and are likely to have more bugs than the latest production release. However, they may include new features and bug fixes that have not yet been released into production and are particularly useful for builders of tools that use or extend NUnit.

More out of habit than necessity, I avoided the Microsoft c:\Program Files directory, and instead installed NUnit into a directory called c:\bin\NUnit2.2.2. I do this because I need to call NUnit both from inside Visual Studio, and from the command line, and my life just seems to run more smoothly if I don’t install NUnit into a directory that has spaces in its name.

The next step is to open up the c :\bin\NUnit2.2.2\bin\nunit-gui.exe.config file in a text editor. You may want to choose an editor such as Visual Slick Edit, that provides syntax highlighting for XML files. In many editors, you will have to take an extra step to inform the editor that this file, which has an extension of .config, is actually an XML file. For instance, in Visual Slick Edit, choose Tools | Options | File Extension Setup, then press the New button.

You now need to find a section of the file called startup. This section of the file is commented out by default, so you need to remove the comments. As you surely recall, XML comments are like HTML comments, and begin with this signature: <!– and end with this signature: –>. This is the point where syntax highlighting can be helpful, as commented code shows up in one color, and ordinary code in another color.

You should now remove or comment out the existing code in the startup section and replace it with code that looks something like this:

	<requiredRuntime version="v2.0.50727" />

When specifying the version number, be sure to look in your c:\windows\Microsoft.NET\Framework directory and see what Framework you are actually using. As Microsoft draws near the ship date for Visual Studio, they are popping out releases like cars from an automated factory, and the version numbers spin by like an odometer on an autobahn. The number you want will begin with a v2.0. For instance, here is the directory listing from my system:

[D:\documents\web\codefez\hardcoded]dir c:\WINDOWS\Microsoft.NET\Framework

 Volume in drive C is unlabeled      Serial number is CC3C:3578
 Directory of  C:\WINDOWS\Microsoft.NET\Framework\*

10/04/2005   9:40         <DIR>    .
10/04/2005   9:40         <DIR>    ..
10/04/2005   9:40         <DIR>    v1.0.3705
10/04/2005   9:40         <DIR>    v1.1.4322
10/04/2005  12:34         <DIR>    v2.0.50727
10/04/2005  10:19         <DIR>    VJSharp

As you can see, the next to last listing, with a time of 12:34, is v2.0.50727.

At this stage, you should be able to run NUnit and begin testing a library that you created inside Visual Studio. In short, the change to the startup section is the only configuration step you need to take to use NUnit with Visual Studio 2005

It is, however, simplest if you can launch NUnit from inside of Visual Studio itself. The process for doing this has also changed. In the Visual Studio Solution Explorer, right click on the Library that you want to test and choose properties. In the picture below, I want to test NUnitDataTests2005, and so I right clicked on it.

In the Properties dialog, turn to the Debug page, select Start External Program, and use the ellipses button to choose the path to nunit-gui.exe In the Command line arguments text box, write in the name of the DLL that you want to test. In my case, it is called NUnitDataTests2005.dll.

Now when you press the run button in Visual Studio, NUnit should be launched automatically and your DLL should be loaded and ready to test. If you get an error about the format of your library, then you should go back to the startup section of your nunit-gui.exe.config file and try experimenting untill you hit on something that works. The option I have shown above, however, works for me on four different machines, and it has worked for many other people.

In this short article you have seen how to use NUnit inside of Visual Studio 2005. The steps involved are not difficult, but I have tried to lay them out clearly so that they will be documented for both myself and others.

On micro-optimizations

What’s a micro-optimization, you may ask? It’s applying a local-in-scope rule about optimization to your code without actually testing to see if it makes any difference to the performance of your application as a whole. Micro-optimizations are generally cast as never-to-be-broken rules, or even as items in some coding standards document.

Examples are easy to find: always using for instead of foreach, appending to a StringBuilder object instead of string concatenation, avoiding small methods to minimize the call time. Or, if you are a Delphi Win32 developer, never using TCollection, not using interfaces because of the reference counting, using other optimization tricks and tips.

Now, before you start huffing and puffing, I’m not advocating abandoning these optimizations, or saying that they are inherently evil, or anything like that. All I’m saying is that you should initially write code as clearly as possible. That implies that your code should be readable, simple and understandable. After all, your code gets written just the once, and then will be read many, many times.

Concentrate, therefore, on writing the clearest, simplest code that satisfies the requirements. Writing clear code gives you the best chance of creating provably correct software and of creating code that is easier to optimize. Writing clear code provides the best opportunity for enhancing maintainability. Far more money is spent on software maintenance than is ever spent on the original code. Clear code is generally more flexible and better able to adapt to future needs and changes. Consider using refactorings guided by software metrics to simplify your code. Consider using your skills as a developer to identify and remove code smells.

And it’s only after your code is written that you get to profile it to test its performance within the application. Only then do you get to analyze the hot spots in your application as a whole. Only then do you get to formulate a thesis ("replacing this simple-to-read foreach with a slightly harder to read for loop will improve the performance of my application as a whole") and then test it with the real application. Only then should you accept code changes that have a measurable change in your application’s performance. Only then should you reject failed theses and revert your code to the simpler-to-read version.

Of course, when you profile, don’t just profile the speed performance of your application. Profile the space requirements too, the memory pressure on the heap (the number and sizes of objects created and destroyed), the stress on the virtual memory system.

And remember that in order to refactor your code you must have unit tests to ensure that you don’t break functionality as you polish the performance.