Problems with NUnit 2.4 Add-In Extensions
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.
3 Comments to “Problems with NUnit 2.4 Add-In Extensions”
Recent Posts
- Top 5 questions to ask when checking references
- Unacceptable: Unit testing will take 20 years to catch on
- The 4 reasons why we DIDN’T choose Oslo
- Typemock Academy Launch
- The First Rule to Software Craftsmanship
Categories
- .NET Tests
- Agile
- Code Integrity
- Community
- Debugging
- Fun
- Management for Geeks
- Marketing
- Product
- Release
- Reviews
- SharePoint
- TDD
- Time Management
- Uncategorized
- Unit Tests
Archives
- August 2010
- May 2010
- April 2010
- March 2010
- February 2010
- December 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- August 2008
- July 2008
- May 2008
- April 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
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