Smooth unit testing with NUnit and VB.NET

Unit testing .NET Fx projects basically is easy with NUnit and I don´t want to add to the literature on unit testing at this point.

However, the devil´s in the detail. To make unit testing a really smooth experience from within VS.NET, the test run should behave like a regular program run as much as possible. Even or especially when testing functionality in a DLL.

For me that means at least:

-Code tested needs access to an app.config file.
-Debugging should be possible if necessary.
-Test errors should be treated like compilation errors in that I can easily find the offending source code line.

Fortunately NUnit fulfills all three requirements, but needs to be tweaked a little bit.

 

1. Your VS.NET project

Setup your VS.NET project as usual.

Be sure, though, to include a reference to the nunit.framework assembly.

Then add test fixture classes to the project.

Compile the project.

2. App.Config

Add an app.config file to the VS.NET project if needed.

Do not rename the config file!

3. Setup NUnit project

Start the NUnit GUI and setup an NUnit project for your VS.NET project. Reference your project´s assembly.

Then go to Project|Edit and change the Config file name to App.Config.

Save the NUnit project which should be named like your VS.NET project and located in the same directory.

4. Autostart NUnit When Debugging

Go back to your VB.NET VS.NET project, and open the project properties.

Go to Configuration properties|Debugging and enter into Start external program:

    C:\Program Files\NUnit V2.1\bin\nunit-console.exe

(If needed adapt the path to nunit-console.exe.)

Enter into Start Options|Command line arguments:

    "..\myapp.nunit" /wait /nologo

The first parameter is the path pointing to the NUnit project located in the same directory as your myapp.vbproj file.

(Change "myapp" to the name of your application´s name. The ".." is necessary, since the startup dir for nunit-console.exe is the bin directory of your application.)

 

Now run the library project in debug mode by pressing F5 in VS.NET. The NUnit console test runner should start, run all tests and show the results. If you like, you can set breakpoints in your code and the test runner will be halted when it reaches them. And you can access your app.config file as usual from within your code, since the test runner will register it with the application domain it creates for executing the tests.

Only one item is still missing from the above requirements lists:

5. Create a Debug Version of NUnit

When running the console test runner all results are shown in its console window. That´s informative, but puts the burden on you to locate the errorenous lines in your source code.

Now the NUnit documentation states, the test runner would detect if it´s run in VS.NET debug mode and output error messages to the VS.NET output window. By clicking on them you are supposed to be taken to the source code.

Alas, at least in my version of NUnit (2.1) this did not work out of the box. No messages showed up in the VS.NET output pane. The reason for this obviously is, the nunit-console.exe test runner included in the .msi installation file has been compiled in release mode.

So what you have to do is open the NUnit V2.1\src\nunit-console\nunit-console.csproj project and recompile the test runner source in debug mode. (No changes to the source code are necessary. But to accomplish that, it´s best to copy the nunit-console directory someplace else (e.g. desktop), open the project, and add references to the nunit.framework.dll and nunit.util.dll. If you don´t do that, you end up opening a pretty large solution with lot´s of NUnit projects in it.)

Once you compiled the nunit-console.exe test runner, copy it to the NUnit V2.1\bin directory.

Now, if you start up your VS.NET project again, the test runner should come up fine, but also show its test results in the output pane of VS.NET. And if you click on one of the failure lines you´ll be taken to the source code line it was caused by.

Happy unit testing!

1 Comment

  • @Jim: I tried NUnitAddIn and it works ok. But app.config handling is not easier compared to standard NUnit. Plus, the error messages in the output pane don´t point to the source code that caused them. The debug version of nunit-console.exe is more comfortable to use in this regard.

Comments have been disabled for this content.