Debug NUnit tests in Visual Studio

While developing the NUnit addin for Lingual, I had to come to terms with something painful.  If I use Lingual for my tests, I lose Resharper support for running unit tests in Visual Studio.  While this tradeoff isn’t bad (the NUnit GUI works fine), it also means I lose debugging support, which can be painful.

If you do BDD right, you find that you don’t need to debug often, but you still do need debugging for those particularly pesky bugs.  Not being able to debug my tests was a nonstarter.  Luckily, I found some tidbits on the internets that led me to the light.  Unfortunately, there’s no “tutorial” style page out there that I thought good enough to link to, so here goes.

In order to debug NUnit tests in Visual Studio, you need to start the NUnit GUI as an external program from Visual Studio.  As best I can determine, this will start NUnit and immediately attach to the process on which it runs.

First, if you don’t already have an NUnit project (*.nunit), open the NUnit GUI and create a new project.  Add your test projects to this.  Save it under your solution directory.

Next, in visual studio, in the project properties of your test project, under the “Debug” tab, click the “Start External Program” radio button.  Point it to the location of your NUnit GUI.  Under “Command line arguments” put the path to your nunit project file.

Now, you can right click on the project and choose Debug > Start new instance.  This will open the NUnit GUI.  Now, if you run a test that has a breakpoint set, Visual Studio will hit that breakpoint as normal.

Alternately, you could set the test project as your startup project.  Do this by right clicking the project and selecting Set as StartUp Project.  Now whenever you run by F5, or Ctrl-F5, the NUnit GUI will start..

There are still some pain points, like with Resharper, you could double click on a test, and it would take you to the method, or double click on a test fixture, and it would take you to the class.  Also, I’ll miss the hyperlinks on the stack trace that take you to the code location.  My hope is, though, that the gains in having an expressive language based testing framework will offset the losses in giving up Reshaprer’s integrated testing.