When developing SharePoint applications, it is common to develop custom:
One of the first things we noticed when trying to unit test our business logic is that our code will heavily relied on elements of the SharePoint API.
A common approach to making code more testable is to identify and isolate services that a class needs to do its work, treat them as external dependencies, and passed them into the class. If these dependencies are passed in instead of being internally constructed, we have the opportunity to pass in a substitute.
By controlling the behavior of the substitute we can force specific branches of our code to be executed. This process of creating controlled substitutes for dependent services is referred to as mocking (http://en.wikipedia.org/wiki/Mock_Object).
It is often very advantageous to use a mock instead of the real service. The classic example is where our business logic handles a “Database Full” exception thrown by a dependent service. We obviously wouldn’t want to simulate that by filling up the service’s database. Rather, we would like to have our mock service simply throw the exception on demand. Unit testing our business logic is basically validating how our code interacts with dependent services. By using mocks in place of the real implementations, we can effectively simulate any condition and examine our code's response to those conditions.
Let’s treat elements of the SharePoint API such as SPWeb and SPList as dependencies that we want to mock. When we try creating a mock of any of these elements we quickly run into a few challenges.
Bottom Line… the SharePoint API is Hard To Mock!!!