16. March 2011 11:45
Fancy writing xUnit.net tests for Windows Phone 7?
I’ve just pushed the latest release of xunitcontrib-silverlight to codeplex. It’s version 0.2 and builds on the first release by including a Windows Phone 7 compatible provider for the Silverlight Unit Testing Framework.
Using it is dead easy, but not exactly seamless – check out this brilliantly helpful post for full details . In outline:
- Create a Windows Phone application project
- Add references to:
In the MainPage.xaml.cs file, modify MainPage_Loaded to create the test page and set it as the RootVisual (see the above post for an example) VERY IMPORTANT: Register the xunit test provider. Simply call XunitContrib.Runner.Silverlight.Toolkit.UnitTestProvider.Register()
- Microsoft.Silverlight.Testing (the Silverlight 3 version – included in the release package)
- (Visual Studio may decide to whinge about adding Silverlight 3 assemblies to a WP7 project. Ignore them, it’s all fine)
If you fail to do this, NO TESTS WILL RUN Write some xunit tests and run the application
Everything else is pretty much as for the desktop (Silverlight) runner:
- The core xUnit.net API is fully supported (Fact, Theory, new test instance per run, IUseFixture, IDisposable, etc)
- ExclusiveAttribute works as a means of filtering which tests to run
- Use traits with keys of “category”, “owner” and “description” to pass metadata into the system (not used much, but nice to know)
- OleDb theories aren’t supported due to lack of Silverlight support. Similarly, capturing output
- Tests aren’t run in random order (they’re run alphabetically)
- Theory tests are enumerated in full before the tests are run, so there is a single test for each instance of a theory test combination. If enumerating tests is expensive, project startup will be expensive
- Silverlight does not support private reflection. This means you might need to use InternalsVisibleTo for xunit-silverlight-wp7
GOTCHAS. There are a couple:
- The namespace displayed for a failing test is incorrect. It’s always displayed as “XunitContrib.Runner.Silverlight.Toolkit”. There is a change currently sitting in source control for the silverlight unit testing framework that will sort this out. Once the bits have been released, this will be fixed properly
- Don’t forget to call UnitTestProvider.Register!
- There is a bug in the xaml for the test page which makes the “Run everything” button invisible. This means that it looks like there’s only the “Use tag” button – and using this button causes the ExclusiveAttribute to be ignored (because you’ve specified what to run with a tag expression). The workaround is to just click it anyway (the yellow rectangle in the image below) – it still works, you just can’t see it. Similarly, this bug is fixed in source control, and will be rolled into a release once the official bits are released.
This release has a couple of other changes to the 0.1 release that are worth mentioning:
- Assemblies are now versioned appropriately. For the xunit files, the file version is the xunitcontrib version (e.g. 0.2) which is the value displayed in Windows Explorer. However, the internal version of the assembly (the number you link against), is set to the version of the xunit assembly
- The xunit assemblies have been renamed to follow a known pattern, namely *-silverlight3, *-silverlight4 or *-silverlight-wp7
- The xunit assemblies now come with xml intellisense docs
So what’s next?
- Well, it’s getting painfully difficult to build from source. I think I’m going to have to bite the bullet and put the xunit port into its own fork
- nuget support
- Ensure support for the Silverlight Unit Test Framework’s base classes, which means ensuring asynchronous tests and the UI test panel work
And of course, anything else that get’s reported. Please list issues at codeplex, or ping me on twitter @citizenmatt.