Click here to Skip to main content
15,867,330 members
Articles / Programming Languages / C#

Debugging NUnit Test Scripts

,
Rate me:
Please Sign up or sign in to vote.
4.63/5 (26 votes)
24 Feb 20045 min read 110.3K   715   42   16
How to debug NUnit Test Scripts
In this article, I show you a way to debug your NUnit test scripts. This trick lets you write test scripts only once and use them twice, for debugging and for unit testing.

Introduction

NUnit is cool. But if not properly used - it can be expensive. Some developers dislike it because they say it doubles their work. Typically, they will develop a short segment of code and step through it with the debugger. After it has been stabilized, they will write NUnit compliant test scripts. Hence, they will either write tests twice or migrate existing ones to NUnit - both actions will require additional effort!

In this article, I will show you a way to debug your NUnit test scripts. This trick will let you write test scripts only once and use them twice: for debugging and for unit testing.

Prerequisites

  • NUnit 2.1 installed to default folder (C:\Program Files\NUnit V2.1)!
  • Visual Studio.NET 2003

The Sample Project

To demonstrate the concept, we will need a small project consisting of two libraries. Each library will contain one function and its tests.

Image 1

Figure 1. Solution

Here is the code for ClassA.cs and ClassB.cs. For now, ignore other files in the solution - I'll explain their meaning later.

C#
// ClassA.cs
using System;
namespace LibraryA
{
    public class ClassA
    {
        public int Add(int a, int b) {return a+b;}
    }
}
// ClassB.cs
using System;
namespace LibraryB
{
    public class ClassB
    {
        public int Mul(int a, int b) { return a*b; }
    }
}

Tests

We will put the test code for each library inside the library itself. Some programmers prefer to put all tests to a separate project. This project then contains test code of the entire solution.

There is a downside to this. Imagine you want to reuse the library. If tests are inside the library, you can simply copy it to the new solution. If not, then you have to extract tests and copy them to the new solution.

C#
// LibraryATests.cs
#if (DEBUG)
using System;
using NUnit.Framework;
namespace LibraryA
{
    [TestFixture]
    public class LibraryATests
    {
        [Test]
        public void Add() 
        {
            ClassA classA=new ClassA();
            Assertion.Assert(classA.Add(10,20)==30);
        }
    }
}
#endif
// LibraryBTests.cs
#if (DEBUG)
using System;
using NUnit.Framework;
namespace LibraryB
{
    [TestFixture]
    public class LibraryBTests
    {
        [Test]
        public void Mul() 
        {
            ClassB classB=new ClassB();
            Assertion.Assert(classB.Mul(10,20)==200);
        }
    }
}
#endif

There are no standards for naming or structuring your tests. I prefer putting them all to one class. The name of this class is <LibraryName>Tests (i.e., LibraryATests for tests for LibraryA). Works good for me but de gustibus non est disputandum.

I also prefer not to distribute tests with release version of software thus I put #if (DEBUG) directive around test fixtures.

Making NUnit Start When We Run the Solution

There are several ways to integrate testing & debugging:

  1. Run NUnit giving it the solution file as a command line parameter and then attach to the process. As soon as you are attached, you can set breakpoints.
  2. Rename NUnit-GUI.exe to NUnit-GUI.dll and initialize & run it from an executable. Markus Kalina described the procedure for this ugly hack in detail here.
  3. Create NUnit surrogate project in your solution and configure it so that NUnit is run every time you try to start it. I find this solution most practical and use it.

To create NUnit surrogate, we first need to create a test project. Test project is a special file with extension .nunit which lists all libraries that contain unit tests. Here are the contents of NUnitTests.nunit test project file.

XML
<NUnitProject>
    <Settings activeconfig="Debug" />
    <Config name="Debug">
        <assembly path="LibraryA\bin\Debug\LibraryA.dll" />
        <assembly path="LibraryB\bin\Debug\LibraryB.dll" />
    </Config>
    <Config name="Release"></Config>
</NUnitProject>

I commonly save this file to solution root folder and add it as solution item. This ensures that the source control systems store it together with the solution.

Next, we create a new console application and add it to the solution. We don't need to modify the code of this application since we'll only use this project as a surrogate to invoke NUnit GUI. If you do change the code, then make sure that it always contains the Main function so that the compiler will not complain. Here is what you can use:

C#
// DummyApp.cs
using System;
namespace NUnitTests
{
    class DummyApp
    {
        [STAThread]
        static void Main(string[] args)
        {
        }
    }
}

Now configure VS.NET to start NUnit-GUI.exe taking NUnitTests.nunit as command line parameter.

Do this by right clicking your console application in the Solution Explorer and selecting Properties. Then change settings: Debug Mode, Start Application, Command Line Arguments, and Always Use Internet Explorer as shown in the figure below. VS.NET is a bit buggy. You will have to first change setting Always Use Internet Explorer to True and Debug Mode to Program. Then you will have to press button Apply. Only then will you be able to edit other fields.

Image 2

Figure 2. Settings to run Nunit-GUI.exe

After confirming new settings every time you try to run the surrogate application, you'll start NUnit GUI.

Image 3

Figure 3. No bugz

Because NUnit GUI will be started by VS.NET, the debugger will attach to the process automatically. You'll be able to select and run tests of the solution (NUnit GUI will show all projects listed in NUnitTests.nunit file) and use the debugger as if you were running your console application instead.

VS.NET User Settings

For some reason, VS.NET stores project settings (Start Action and Start Application from Figure 2) to user settings file (with extension .user). Settings are stored to NUnitTests.csproj.user in the NunitTests project folder (NOT in the solution folder). Following is the subset of this file:

XML
<VisualStudioProject>
  <CSHARP LastOpenVersion="7.10.3077">
    <Build>
      <Settings ReferencePath="">
        <Config Name="Debug" EnableASPDebugging="false" 
        EnableASPXDebugging="false" EnableUnmanagedDebugging="false"
          EnableSQLServerDebugging="false" 
          RemoteDebugEnabled="false" RemoteDebugMachine="" 
          StartAction="Program"
          StartArguments="..\..\..\NUnitTests.nunit" 
          StartPage="" 
          StartProgram="C:\Program Files\NUnit V2.1\bin\nunit-gui.exe"
          StartURL="" StartWorkingDirectory="" StartWithIE="true" />
      </Settings>
    </Build>
  </CSHARP>
</VisualStudioProject>

The problem is that user settings are not checked in to the Source Safe when you check in from VS.NET. Thus, next time you check out the entire solution (say, to another machine), your settings are lost and you have to reconfigure the project.

I have not found a good solution for this problem. At present, I manually check in and check out UnitTests.csproj.user. I only have to do it once per machine because subsequent check ins and check outs will not affect user settings file. Let me know if you find anything better.

History

  • 25th February, 2004: Initial version

License

This article has no explicit license attached to it, but may contain usage terms in the article text or the download files themselves. If in doubt, please contact the author via the discussion board below.

A list of licenses authors might use can be found here.


Written By
Founder Wischner Ltd
United Kingdom United Kingdom
Writing code since 1982 and still enjoying it.

Written By
Web Developer
Switzerland Switzerland
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

 
GeneralIt's posible to run immediatly NUnit tests... Pin
insertto@wp.pl22-Jun-08 23:51
insertto@wp.pl22-Jun-08 23:51 
GeneralTDD Pin
TimMoore122-May-07 23:57
TimMoore122-May-07 23:57 
GeneralNot trying to sell the product but Pin
mr_lasseter1-Feb-07 14:39
mr_lasseter1-Feb-07 14:39 
GeneralThanks Pin
spin vector1-Apr-06 6:21
spin vector1-Apr-06 6:21 
GeneralNice! Pin
peterchen29-Jan-06 0:21
peterchen29-Jan-06 0:21 
GeneralSolution to version control problem Pin
makiwa2-Aug-05 9:47
makiwa2-Aug-05 9:47 
Hi guys,

"The problem is that user settings are not checked in to the Source Safe when you check in from VS.NET....Let me know if you find anything better."


I managed to sort this one out. Check out my blog post: http://www.makiwa.com/index.php/2005/08/02/test-driving-class-libraries-with-nunit-and-visual-studio-2003/[^]

Stu
GeneralRe: Solution to version control problem Pin
spin vector1-Apr-06 7:03
spin vector1-Apr-06 7:03 
GeneralIntegrate test code into the library Pin
ejp107-Apr-05 1:32
ejp107-Apr-05 1:32 
AnswerRe: Integrate test code into the library Pin
Benson8814-Aug-06 4:33
Benson8814-Aug-06 4:33 
GeneralRe: Integrate test code into the library Pin
Benson8814-Aug-06 4:38
Benson8814-Aug-06 4:38 
AnswerRe: Integrate test code into the library Pin
Benson8814-Aug-06 4:42
Benson8814-Aug-06 4:42 
GeneralRe: Integrate test code into the library Pin
Phil Boyd12-Mar-07 7:52
Phil Boyd12-Mar-07 7:52 
GeneralRe: Integrate test code into the library Pin
SimplyConfuzed26-Jun-07 12:05
SimplyConfuzed26-Jun-07 12:05 
GeneralThanks for the QuickStart! Pin
Ed Sutton7-Feb-05 11:05
Ed Sutton7-Feb-05 11:05 
Generalstarting both IE and nunit Pin
Member 135430126-Sep-04 23:33
Member 135430126-Sep-04 23:33 
GeneralThe only way to go Pin
John Miller3-Mar-04 13:57
John Miller3-Mar-04 13:57 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.