kamagra how much to take

Using TypeMock.NET To Abstract SharePoint With Mocks

On my current project, I am developing some pretty intensive SharePoint WebParts that would otherwise take a ton of time when actually making tangible calls to either the SharePoint object model or database. For this reason, I took the advice of some straight .NET development colleagues with the .NET community and started using mock objects, specifically TypeMock.NET (which, after testing a variety of frameworks, I am finding the most solid while being updated the most frequently).

For those that aren’t familiar with using mock objects with SharePoint, or mocks objects as a whole, you can use a Mock Object as a way to simulate an object instance, incorporating all the behavior of that object, so that you can bypass the expensive need of calling components to otherwise get the calls to work (working together directly within Unit Testing, which will subsequently increasing the overall quality and outcome of your testing). Using mock objects, you can structure a design pattern for your code to run as it would both locally regardless of if you have access to your SharePoint instance since you will be mocking this calls, and then also have a non-mock instance that will eventually become your production deployment package. Your design pattern would in essence keep this synchronized. Furthermore, when using a mock framework, you promote a loosely coupled series of code instead of one that is irrevocably bound to SharePoint (more or less),
The problem that I was running into with SharePoint and mock objects was a relatively straightforward one, for some reason the development team for API support at MSFT decided to seal a bunch of the classes I wanted to mock, and my preferred mock object frameworks don’t support that genius move. To even make the situation worse, a majority of the SharePoint classes are decorated with internal constructors, which limits a bunch of the SharePoint classes so they cannot be instantiated outside of the assembly. Why they are dressed as such, I am not aware.

Nonetheless, I simply wanted to speed up some of my development, and after a bunch of failure, was able to get some rudimentry work done with TypeMock.NET.

Firstly, create a new method that will contain your mock objects. I am going to call mine ExampleSharePointTypeMock().

  1. public void ExampleSharePointTypeMock()
  2. {
  3.  
  4. }

Next, place the decorations in front of the method for directives when the method is called. We are going to use the VerifyMocks attribute above the method whose decorator, whose name implies, verifies the mocks at the end of the unit tests that we are going to perform (this can be extended using the Typemock-Isolator to create the such decorations, however it is beyond the scope of this current post) .

  1. [TestMethod,VerifyMocks]
  2. public void ExampleSharePointTypeMock()
  3. {
  4.  
  5. }

Now, we actually have to start to create the mock objects that we are going to use. This is really not that tough, and using TypeMock.NET we are able to bypass several of the limitations that are present in several other mock frameworks. These are simply the issues that we talked about in the beginning of this post regarding class sealing and internal constructor use. In order to create some simple SharePoint mock objects, for example a SharePoint list (SPList object) and a SharePoint List Item (SPListItem object) we are going to use the RecorderManager.CreateMockedObject method (you can find out more about this when browsing the Typemock Isolator API Documentation) which will take the type that we wish to mock, outputting the mocked object. So how is it used? Let’s take an example with a simple class to mock, with a whole pile of nothing in it.

  1. public class ClassToBeMocked
  2. {
  3.  
  4. }

Then if we wanted to output a mock object from this class, we us the CreateMockedObject method.

  1. [TestMethod,VerifyMocks]
  2.  
  3. public void MockMethodTest()
  4. {
  5.  
  6. ClassToBeMocked mockedObject = RecorderManager.CreateMockedObject(typeof(ClassToBeMocked)) as ClassToBeMocked;
  7.  
  8. }

Therefore, in order to do the same process with SharePoint, we can just call the orthodox SharePoint objects in a similiar fashion.

  1. [TestMethod,VerifyMocks]
  2. public void ExampleSharePointTypeMock()
  3. {
  4.  
  5. SPListItem mockedSPItem = RecorderManager.CreateMockedObject(typeof(SPListItem)) as SPListItem;
  6. SPList mockedSPList = RecorderManager.CreateMockedObject(typeof(SPList)) as SPList;
  7.  
  8. }

As you can see in the above, we are passing in the two SharePoint types, namely SPList and SPListItem, as parameters in order to create the two mock objects, which after hydration will subsequently be available to us in later code. This is consistent even though the object model has really stupid limitations within it. I am going to do a really simple test, test whether the item name equals the list name.
Afterwards, we are going to use a new RecordExpectations object which as the name implies is a way of managing and setting expectations. We will put this object within an using statement so that when this object is instantiated, we ensure that when we are done with the object, the object’s Dispose method is called at the appropriate time. This, in when executed in MSIL, will get converted by the CLR into try / finally blocks.

  1. public void ExampleSharePointTypeMock()
  2. {
  3. SPListItem mockedSPItem = RecorderManager.CreateMockedObject(typeof(SPListItem)) as SPListItem;
  4. SPList mockedSPList = RecorderManager.CreateMockedObject(typeof(SPList)) as SPList;
  5. using (RecordExpectations recorder = new RecordExpectations())
  6. {
  7.  
  8. }
  9.  
  10. }

We have to set the behavior of this object following which can be a number of properties, I am not going to set it for this example but it helps when restricting unit tests.

Following, we are going to use the ExceptAndReturn method in order to pass in a call, and a secondary argument to conditionally pool the test. In this case, I am going to make sure that the names are well-formed and available, satisfying the conditions I want. You can then use the Assert.AreSame method in order to do further checking to asset whether the correct values are being passed.

  1. public void ExampleSharePointTypeMock()
  2. {
  3.  
  4. SPListItem mockedSPItem = RecorderManager.CreateMockedObject(typeof(SPListItem)) as SPListItem;
  5. SPList mockedSPList = RecorderManager.CreateMockedObject(typeof(SPList)) as SPList;
  6. string listName =  mockedSPList.Name;
  7.  
  8. string itemName =  mockedSPitem["Title"].ToString();
  9. using (RecordExpectations recorder = new RecordExpectations())
  10. {
  11. recorder.ExpectAndReturn(listName, "test");
  12. recorder.ExpectAndReturn(itemName, "test");
  13. }
  14.  
  15. }
  16.  
  17. Assert.AreSame(listName, itemName);

So this example could have been a little more robust and the test is a little redundant I know, however it gets the point of the functionality around I guess.

:)

Share

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>