Like it or not, whoever wants to have a stable code, need to write unit tests. There are 2 main unit testing frameworks for .Net Environment: MBUnit and NUnit.  During this post, I am going to focus on NUnit and its integration with Visual Studio in particular.                               

Once we wrote our unit tests and compiled them, an assembly file is created which can be executed using the NUnit framework. We can run those tests directly from NUnit GUI or NUnit Console, but running our tests from Visual Studio is much more convenient and faster (assuming that we are in the middle of the development process with VS).

1. The first and most obvious way is to start NUnit as an external program. This goal can be achieved by right clicking on the unit tests project -> choosing the properties option -> selecting the Debug tab -> choosing “start external program” radio button instead of “start project” (which is the default option) and enter NUnit assembly location. We are not done yet, the “command line arguments” section shall be filled too, otherwise, NUnit will not necessarily run our unit test. If NUnit has no command line arguments, it is opening the last assembly which was loaded into it. So, the command line argument shall be the location of our unit test assembly.
2. The second way to achieve our goal is using plugins. ReSharper and Test Driven .Net are 2 great plugins (ReSharper has much more functionality and is not solely focused on the unit tests, while Test Driven .Net does), I will show my case using Test Driven .Net.  It is very simple, just right click on any test, unit test file or the project file and we get “Run Test” option in the context menu. What do we have to do now? just clicking on that menu item and our unit tests are running. It is important to mention that the plugin has more options, but this is not the subject of that post.
                                                   
3. The third way involves some code writing. First, the assembly type shall be exe and not dll and there shall be a main method in the code with the [STAThread] attribute. Then, add the “nunit.core.interfaces” assembly as a reference to the project file. In the main method call Class1.Main() with the name of our executing assembly as a parameter. Don’t you think someone in the NUnit team forgot to rename Class1 name ? I do…

   1: class Program

   2:  {

   3:      [STAThread]

   4:      static void Main(string[] args)

   5:      {

   6:          Class1.Main(new string[] { Assembly.GetExecutingAssembly().Location });

   7:      }

   8:  }

OK, so we covered some ways to run NUnit from Visual Studio. There is one more issue that shall be taken into consideration and that is, the AppDomain (Represents an application domain, which is an isolated environment where applications execute). What will the running AppDomain be in any of the possibilities mentioned above? NUnit or our unit test executable?

When we run NUnit as an external program or using a plugin, NUnit exe will be loaded as the default application domain. When NUnit is called from code (way #3), the AppDomain is our unit tests executable. Why is that so important you wonder? Well, that depends on our code, but i can warn you about one issue i ran into.

If an app.config file is used (file that is intended to store static values or settings for your application) and the running AppDomain is NUnit, we will get default values and not what’s in the configuration file. That is surely unwanted, so be aware of that, following way #3 will keep us away from this “obstacle”.