Running NUnit 2.53 tests for Silverlight

Jeff Wilcox has described in this article how to make NUnit tests run in the Silverlight unit testing framework. That article provides all the groundwork for what you need to do:

• Compile a version of the NUnit framework that runs in the Silverlight 3 context
• Provide metadata for the Silverlight unit testing framework so it knows which attributes to look for in order to locate what method is a test (and a little more)
• Register this metadata in your Silverlight unit test project.

I’d like to thank Jeff for his great work, and provide some raisins on top: an update to version 2.53 of NUnit. Here’s what’s to do:

• Take the compatibility shim and test metadata provider from Jeff’s article.
• Download the current NUnit source code (in this case 2.5.3). Create a new Silverlight project, and add the code for the NUnit framework into it. Compile: a whole bunch of exceptions come up.
• NUnit’s source code uses the #if precompiler directive in order to exclude parts that are incompatible with different version of the runtime. By defining the NET_2_0 symbols, we can make a lot of the errors disappear: the nongeneric implementation of Stack, for example, is excluded now. We need to exclude some more code: Instead of deleting it altogether, I chose to use the SILVERLIGHT symbol and add a #if !SILVERLIGHT directive to get rid of unsupported code instead. In cases where a whole method body is excluded, add a section on the bottom that throws a NotSupportedException:

  #if SILVERLIGHT
        throw new NotSupportedException( "Not supported in Silverlight" );
  #endif
  

• We need to get rid of the serialization constructors from all the exceptions.
• Remove the attributes for threading demands – they’re useless in Silverlight anyway.
• Remove the attributes for threading demands – they’re useless in Silverlight anyway.
• Add a new shim class for the non-generic System.Collections.Specialized.ListDictionary to the Compatibility project. It is a simple derivation of the genetic Dictionary.
• In the PathComparison class, there are some unsupported string operations. I didin’t bother exluding and replacing these, and just refactored them to supported alternatives. (Thinking about it, I should probably have used the .NET2.0 switch. Next time, promised)
• Finally, the metadata provider uses a changed property for in the ExpectedException attribute. Corrected, aaaaaand…
• Done. Now all you need to do is reference the three generated assemblies, follow Jeff’s article on how to set up the testing framework for the NUnit provider, and start writing tests.

This was easy enough that I hope it can be done for any upcoming version of NUnit.

The point where I’d like to disagree with Jeff Wilcox the idea that NUnit was a legacy solution, and that you should start new projects with Visual Studio testing. NUnit provides much richer assertions, and a better syntax for setting them up: you won’t find assertions for examining collection content or thrown exceptions in Visual Studio testing. Or the upcoming ability to run tests in parallel compartments to simulate a distributed environment. NUnit is far from being a discontinued legacy solution, it is the de facto standard and quickly developing. And: thanks to the extensibility of the Silverlight unit testing framework, there’s not a reason not to use it for Silverlight as well.

UPDATE

The project is now hosted as nunit-silverlight on Google Code.