One of the major problems when it comes to NUnit extensibility is the limitation that you must deploy your Addins in a subfolder (named ‘addins’) under the installation (or run) path of NUnit, so if you build some customization and extension and you want to deploy them on a build machine (or a Continous Integration machine) you need to build ad-hoc scripts and build actions.

To overcome this problem I’ve written a very simple and small addin that allows you to specify, in the configuration file of the test assembly, a set of DLLs that contains the addins to be loaded when the test start.

So once you have deployed this addin to your testing environment you can forget about any other script or action needed to load all the other extensions you develop to extend your test architecture.

The project is divided in 2 assemblies:

• Structura.NUnitExtensions: actually contains the ConfigrationSection customization to load the info from the config file.
• Structura.NUnitExtensions.Addins: contains the implementation of the addin, this is the only project that depends on NUnit.core.dll, and it will need to be compiled against the NUnit version you are using.

here’s the core class:

   1: [NUnitAddin(Name = "AddinsLoaderAddin", Description = "An addin to dinamically load other addins")]

   2: public class AddinsLoaderAddin : IAddin

   3: {

   4:    #region IAddin Members

   5:  

   6:    public bool Install(IExtensionHost host)

   7:    {

   8:       AddinSectionHandler config = (AddinSectionHandler)System.Configuration.ConfigurationManager.GetSection("nUnitAddins");

   9:       if (config != null)

  10:       {

  11:          // parse the addin data to load from the application configuration file

  12:          foreach (Addin addin in config.Addins)

  13:          {

  14:             // this is used by the core to load and use them

  15:             Assembly asm = Assembly.LoadFrom(addin.Path);

  16:             CoreExtensions.Host.InstallAdhocExtensions(asm);

  17:          }

  18:       }

  19:       

  20:       return true;

  21:    }

  22:  

  23:    #endregion

  24: }

As you can see this is a ‘fake’ addin, it really does nothing but to scan a set of DLLs and register any addin it can find inside them. I was forced to take this approach cause we need to load the addins just before the actual TestFixure classes are parsed and the the TestSuite built and I couldn’t find any better way to configure NUnit and tell it where to look for addictional Addins.

NUnit does indeed have some weak points in its configuration section.

To use this addin you need to add a reference to Structura.NUnitExtensions (or the assembly you use to define the SectionHandler) to your test assembly, and write down some configuration like:

<configSections>

   <section name="nUnitAddins" type="Structura.NUnitExtensions.AddinSectionHandler, Structura.NUnitExtensions"/>

</configSections>

<nUnitAddins>

   <addins>

      <add path="NUnitExtension.dll" />

      <add path="C:\NUnitExt\NUnitExtension2.dll" />

   </addins>

</nUnitAddins>

The section must me named ‘nUnitAddins’ and as you can see you can specify:

• Absolute paths
• Relative paths: the startup path is the working directory of the process that launches the tests.

To let the relative paths work with my modified version of NUnitit I had to tweak the code a bit and to set the working directory of the process that runs the tests (nunit-console.exe or nunit.exe) to the directory where the tests are compiled by Visual Studio (that is the bin/debug directory of the current test).

Here are the links at all the projects:

NUnitit updates:

Related Content

• NUnitit: Visual Studio Addin to support NUnit and some customizations to it (26/08/2015)
• NUnit: Twitter notification Addin (07/10/2009)
• Resharper and the OutOfMemoryException problem (26/08/2015)
• Spot Hidden Exceptions using IntelliTrace (26/08/2015)
• Visual Studio 2010 designer error: Value cannot be null. Parameter name: objectType (26/08/2015)
• More related document (11)