Makiwa

Recently, I was developing a class library project in Visual Studio 2003. I wanted to do Test Driven Development with NUnit, and use NUnit as the debug harness for my library. I tried several approaches but none of them seemed to work well for me.

My main requirements were that:

1. It should be version control friendly (shouldn’t require additional setup steps after checking it out from version control – it should just work).
2. You should be able to debug the class library by setting one or more breakpoints and then just running a test.

Fortunately, perseverance has triumphed over ineptitude and I have come up with a solution.

What follows is a step-by-step guide to setting it all up.

1. Install NUnit
   I am currently using NUnit 2.2. Download a copy from the NUnit website (www.nunit.org) and install it.
2. Create a blank solution
   By creating a blank solution first and then adding the project, you don’t end up with the solution and project files in the same place. This isn’t critical but it helps if you ever add other projects. That way your solution file will be in the logical place - the folder above all of the projects.

   I created Solution1.sln in a folder called Solution1.

3. Add a new Class Library project to that solution.

   

4. Add a test class
   Add a new class called Class1Tests.

   

5. Add a reference to NUnit framework

   

6. Add a new test
   In Class1Tests.cs you need to add a using statement (NUnit.Framework).
   You should then add a [TestFixture] attribute to the class.
   Now create a stub test method: CreateClass1. This new method needs a [Test] attribute.

   You can now build the project.

   

7. Open the class library in NUnit
   Run up NUnit and click File | Open… and select your newly build class library DLL.

   

   You can run the test if you like - it should pass.

   

8. Save the NUnit project
   Now you need to save the NUnit project. The NUnit project file is an XML file (surprise) that points to the assemblies that NUnit should load.

   Click File Save As…, but don’t save it in the Debug folder. Rather go up a couple of levels and save it in the project folder. Call it ClassLibarary1.nunit.

   

9. Setup NUnit as the class library’s startup process
   Back in Visual Studio, select the ClassLibrary1 project in the Solution Explorer.
   Right-click and choose Properties.

   Expand “Configuration Properties” and then select “Debugging”.

   

   Set “Debug Mode” to “Program”. Then click Apply.

   

   Set “Start Application” to the path to nunit-gui.exe. The default is “C:\Program Files\NUnit 2.2\bin\nunit-gui.exe”.

   

   Set the Command Line Arguments to the relative path to the NUnit project file (the ClassLibrary1.nunit file we saved in the previous step).
   This should be “..\..\ClassLibrary1.nunit” (the relative path from \ClassLibrary1\bin\Debug, to \ClassLibrary1).

   

   At this point, if you hit F5 to run the project, NUnit will launch, load ClassLibrary1.nunit, load the referenced assembly (ClassLibrary1.dll) and display all of the tests. Great!

   If we set a breakpoint on the instantiation of Class1 in the CreateClass1 test and we run the test - lo and behold the debugger breaks on the breakpoint.

   

   The power of this is not so much that you can debug your tests, but rather that you can easily debug any arbitrary part of your class library just by running the associated test. Joy!

   But we are no there just yet.

   If we were to check this into version control and someone else were to check it out, it would not work.

10. Making it version control friendly
    The reason it will not work is that, by default, the Debugging Configuration Properties (where we told it to launch NUnit) are stored in a user-specific file. In our case, ClassLibrary1.csproj.user. There is no point checking this file into version control because, when someone else checks out the project and loads it up, Visual Studio will create a new ClassLibrary1.csproj.user file for them - by copying values from the project file.

    So how do you check in the Debugging Configuration Properties?

    When I looked at the two files (ClassLibrary1.csproj and ClassLibrary1.csproj.user) I saw that the both had the same schema (VisualStudioProject | CSHARP | Build | Settings | Config). The relevant sections of the two files are as follows:

    Debug config for ClassLibrary1.csproj.user
    

    Debug config for ClassLibrary1.csproj
    

    So, I tried copying the Start-related attributes from the user file to the project file and…miracles of miracles…it works a treat.

    Debug config for ClassLibrary1.csproj after adding Start-related attributes
    

So, there we have it. All requirements met: we can use NUnit as the test harness, the debug harness and other developers can check out the project and do the same.

Note: If developers have installed NUnit in different drives or folders they can use the user-specific project file to overrride the default setting. They only need to do this once, either through the Configuration Property editor, or by editing the user-specific project file directly.

This entry was posted on Tuesday, August 2nd, 2005 at 19:42 and is filed under Agile Development, Extreme Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.