If you’re creating a Web Part with complex business logic you’ll want to unit test it. Unfortunately you can’t use Visual Studio 2010’s unit tests to test SharePoint 2010 Web Parts. The main problem is that MSTest.exe which is responsible for running unit tests is still a 32-bit application. So it can’t load SharePoint 2010 DLLs as they will only run in a 64-bit process.
You could use NUnit to remedy this but that still leaves you with a lot of work as you have to mock types like SPSite, SPUser–pretty much everything SharePoint. You could also create your own testing harness that exercises your Web Part inside SharePoint. But that would be a lot of work as well.
A drawback of the tight client integration is that it requires a specialized connector for each platform and even for each browser. Currently only Internet Explorer 7 and 8 are supported. But support for FireFox is underway as is support for Silverlight 4.0.
Combine the two features to get the best of both worlds. Automating the interaction with coded UI tests saves you a lot of coding effort. And using the client OM you can do everything that would be impossible or too laborious using coded UI tests–especially setting up and tearing down SharePoint objects like sites, groups, and users for your tests.
OK, you don’t get true unit tests with this as you can’t test private methods and running coded UI tests tends to take much longer. But it’s a pretty slick way to do integration tests or just save yourself a lot of work when automating SharePoint tests in general.
Caveat: you need Visual Studio Premium or Ultimate to use coded UI tests.
More details on using both features in future posts.
- For a list of supported platforms for coded UI tests follow the first links in this blog post
- For details of Microsoft’s testing tools 64-bitness see this blog post
- For a general discussion of the problems surrounding unit testing SharePoint see this blog post