Home » TDD » Run NUnit from Visual Studio

Run NUnit from Visual Studio

For the purposes of this post, I’m going to assume that you already have the NUnit Test Runner installed.  The question you are looking to get answered is, “How do I run NUnit from Visual Studio” or even more importantly, “How do I DEBUG NUnit test from Visual Studio”.  The following step by step should help you.

Right click on the project in Solution Explorer that represents your test project. From the resulting menu, select “Properties.” In the resulting window, selec the “Debug” tab from the left-hand side of the window.


You will want to select “Start external program” and point it to the UNnit runner that got installed when you installed NUnit.

Now, whenever you run this project, with or without the debugger, NUnit will start up. Note: there is no reason to pass parameters telling it what DLL you want to run because it will load the last DLL it had up. But, if you wanted to do that, you could pass the location of the DLL as a parameter to the GUI runner. There are other parameters you can us. Check the documentation for the version of NUnit you are using for the specifics.

If you are running .NET 4.x, you’ll want to go to the location in your file system where NUnit.exe lives and find the NUnit.exe.config file. Find the startup element (<startup> …. </startup>) and place this line in between the open and close startup tags:

<supportedRuntime version="4.0" />

If you miss this step, you won’t be able to debug your 4.0 code. Alternatively, you can just set your project to use .NET 3.5.

So, let’s give it a try.

First, put some code in the test method you just created. For our purposes, we’ll just put in a console writeline so we have somplace to put a breakpoint.

public void MyFirstTestMethod()
    Console.WriteLine("Inside MyFirstTestMethod");

Next set a breakpoint on the Console.WriteLine method and then run your project with the debugger.

Once NUnit loads the DLL, click the “Run” button in NUnit. If everything is setup correctly, you should stop on the breakpoint you set.

You may have noticed that we put several Console.WriteLines() in our code but they aren’t displaying anywhere.  So, where did they go?  How can we see them?

By default the “Text Output” tab displays all of the Console.WriteLine() messages as well as all of the test results.  If all you care to see is the test results, you should select the “Errors and Failures” tab.  Personally, I prefer to work in the “Text Output” tab and I suggest that you do the same.

As an alternative to this, you can just pick up a copy of ReSharper, which has an NUnit Test Runner built into it.  All you need to do to debug a test is selection the test and choose debug from the context menu.  It will save you a ton of time.

Another option would be to pick up the MS Test Adapter from nunit.org.  But, I’ve never liked the way MS Test renders the tests results.  So, I don’t recommend it.  Obviously, your mileage may vary.


Other post in TDD

Related Post

  • What is SpecFlow…What is SpecFlow… …And why do I want it? That’s what I kept asking myself every time I saw this product.Well, the last time I looked, something caught my eye enough that I decided to download it and […]
  • NUnit 2 vs NUnit 3.  What you need to know.NUnit 2 vs NUnit 3. What you need to know. NUnit 3 recently released and if you’ve picked it up you’ve probably already found that there are several changes between version 3 and version 2.If you haven’t, here are some […]
  • Running Selenium In Parallel With Any .NET Unit Testing ToolRunning Selenium In Parallel With Any .NET Unit Testing Tool Running Selenium in parallel from .NET seems to be a problem because, as of the time of this writing, I’ve yet to find a viable way of running selenium test on multiple browsers using […]
  • NUnit & Visual StudioNUnit & Visual Studio Many people starting out with Unit testing get stuck when it comes to using their tools with the Visual Studio environment.  If it isn’t built in, how do we make it work with […]
  • Debugging SoftwareDebugging Software It amazes me how rare the skill of debugging software is.  It is even more amazing to me that after programming for over 27 years now, I still have trouble with this.  So, as a […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.

2 Pingbacks/Trackbacks

  • Pingback: Dew Drop – April 30, 2015 (#2004) | Morning Dew()

  • Pingback: Automate the Planet()

  • Hi Dave,

    Great article!

    Can you please share why you don’t like the MSTest default results?

    As you mentioned at the end of the article, the whole NUnit integration is built-in in the new versions of Visual Studio (> 2012). Thus, I’m not sure why it is necessary to put all of this effort if you have a pretty handy feature built-in.

    Also, I included your fantastic article in my weekly roundup, you can check it here: http://automatetheplanet.com/compelling-sunday-24-posts-on-programming-and-quality-assurance/


    • I prefer the nested rendering that NUnit and ReSharper provide. MS Test renders everything flat.

      You are correct that the latest versions of Visual Studio have MS Test included, but Visual Studio Express does not, nor do all of the versions of Visual Studio prior to 2012. Unfortunately, there are still some companies that haven’t felt the need to upgrade who could benefit from Unit Test.

      So, running NUnit from Visual Studio is A way, but not the only way as I acknowledge in the article.

      Thanks for the links.

      • Yeah, I guess you are right.

        Maybe I have had the luck to work in a company where I’m able to use always the latest version of everything.

        Also, you are right about the flat structure of MSTest results. In my team, we have set up the test results to be published in Jenkins. I enjoy how they are rendering now. You can check it.

        • Seeing them render in Jenkins is cool, but I would hope developers are running unit test prior to checking the code in and potentially breaking the build.