Unit Testing SharePoint Code

原文链接：http://www.kindohm.com/archive/2005/05/02/428.aspx

 

 

A few coworkers and I are working on ways to incorporate unit testing into SharePoint object model development. The main challenge is that SharePoint only allows code to execute against it if the code is running locally. In other words, you can't develop with the SharePoint object model and run the code against a remote SharePoint server.

This constraint is a bit of a headache with respect to unit testing. Unit testing frameworks such as NUnit and add-ins such as Test Driven .Net allow the developer to immediately unit-test their code as they write it. However, SharePoint code can only execute directly on the SharePoint server and the code must be deployed before it can be unit tested with any testing framework.

Testing on the Workstation

One way to address this would be through mock objects. Mock objects can be used within unit tests to test things like API and database calls. They essentially simulate the behavior of a real object that you would use for some operation, but do not actually perform any action. At first glance, mock objects appear to be a good fit for unit testing SharePoint code because they would allow us to test our own code without having to use a live SharePoint environment or the real SharePoint object model.

We looked into using NMock mock objects for use with NUnit. At first, we attempted to mock the SharePoint API directly, but quickly found problems with this as the NMock framework requires that classes being mocked must have default constructors. Unfortunately, most SharePoint classes do not have default constructors and we couldn't get most of the mock objects to work. NMock.org also recommends against mocking someone else's API as it requires you to make assumptions about the API and sometimes create complex tests.

We plan to continue trying mock objects by creating our own SharePoint API wrapper and mocking our wrapper (rather than mocking the SharePoint API). We'll start with a simple piece of functionality and see if we can prove the concept before we build out more of the wrapper.

Testing in the SharePoint Environment

A different approach is to deploy the code and tests to the SharePoint environment, then execute the tests. We'd like to avoid this option as it will slow and increase the complexity the development process. Developers will need to deploy their code, then fire the tests remotely from a test client rather than the VS.Net IDE.  In build environments where an automated process builds an entire solution from source control, it would also require that the build process runs in a SharePoint environment - otherwise the tests will fail.

Run SharePoint on the Workstation

The last option is to have developers run the SharePoint environment on their local workstations. This requires Windonws 2003 Server, and the Dell Inspiron 8600's that we use have devices that are not supported under Win2k3 Server.

Testing Other SharePoint Code

We haven't tackled testing Web Parts or "Smart Parts" yet. However, "Smart Parts" are essentially built around an ASP.Net User Control which can be tested with NUnit ASP. Web Parts are ASP.Net Server Controls that must run within a SharePoint context.

...

As we make progress I plan on reporting what we have learned and what we decide to do. If anyone has worked with similar challenges of testing APIs that have restrictions on being run in certain environments, I'd like to hear your thoughts.