NUnit 2.4 has a new extension feature called NUnit Add Ins. With these Add-Ins it is possible to extend NUnits capabilities without hacking the NUnit code base. This is a great step forward, although it is a feat that MBUnit has been doing for quite some time now.
The best way to understand how to write an Add-In is to download the source files and browse the examples in the samples\Extensibility\Core\ directory.
To install an Add-in copy it to the addin directory.
There is an undocumented feature that installs Add-Ins that are defined in the tested assembly, this is done by searching for an Attribute on all the Types in the assembly. The only reason that I know about this feature is that our tests failed once we upgraded to NUnit 2.4.
Our NUnit assemblies are part of the source code tree – a good practice as it allows the build to be repeatable, without requiring installations.
But NUnit kept on telling us that it couldn’t find an nunit.framework.dll (!?!). We fixed this by telling visual studio to copy the dll to the output directory (reference->Properties->Copy Local->true).
The reason that NUnit crashed, was because it was searching for the NUnit AddIn Attribute in our test assembly (and was doing this after changing the working directory)
What is completely missing from this feature is an easy way to install add-ins. Copying dll’s to addin directories simply doesn’t cut it. To Install an addin, you will have to search for all the addin directories of all nunit installations!!!
The install.bat that is distributed with the examples should have been a big sign that this deployment strategy is flawed.
Guess what, the NUnit guys are nearly there, just extend that pesky NUnit Attribute search that you are doing for the test assembly to all referenced assembly too and viola, there is no need to install the extensions.
Perhaps because of this, Jamie’s – TestDriven.Net doesn’t support NUnit Attributes yet, rendering the extensions to more or less useless.
I also like to mention that Addin activation is done in the order in which they are found within the dlls. Which means that when using the option to extend Test Decorators (attributes) they might not be activated by the order in which they appear in the test definition, instead they are activated by the order in which they are found by the NUnit search mechanism (MBUnit has addressed this issue)
Looking in the source is certainly one way to see how add-ins work, but I’d suggest that folks trying to get started may benefit by reading the docs. 🙂
The business about being unable to find adhoc extensions defined in the test assembly would make a good bug report.
Charlie
Charlie,
Sorry, the docs that I found did not really help very much, With the examples it was a breeze.
Unless I didn’t find the correct docs.
I have reported the bugs and fixes
NUnit fails with nunit.framework.dll not found
Adhoc Addin Installation in cumberson