In this article we will see how to test your sharepoint repositories, as we said before writing unit test for them isn’t easy. I don’t think you can test drive them or that it would help, at the very least it would be too slow.
Therefore SHP repositories are a weak point in your testing strategy, but at the very same time they are the base on which the rest of your application sits on. So it is very important that you do two things:
- Write KISS repositories
- Write integration tests for them
KISS: Keep It Simple Stupid
Your repositories need to be simple, strip them of any logic that has a reason to be somewhere else. Any constraint that isn’t strictly related to the persistent layer should be checked by another layer.
They should receive an entity from above and persist it like it is, if the entity comes with errors those errors will be persisted (or the layer bellow will throw an exception).
Expose a basic API. Instead of a method Save that check if the entities exists and then decides whether to update it or create a new entity expose three basic methods (Exists, Create, Update) and let the layer above make that decision.
Once you have a KISS repository you need to secure it the best you can. This is done by writing tests integrated with sharepoint. Usually to do this you will have to do the following things:
- Create a test site collection
- Provision your artifacts (Fields, ContentTypes, Lists…)
- For each test
- Populate one or more list
- Run a test
- Clean up
- Delete the site collection
This is obviously a very slow process so you won’t run this tests in your normal TDD cycle, but you can run them frequently enough that you will catch most bugs before they can cause any major problem.
Now let’s put aside the theory and write some code, starting from the repository of the previous article
|private const string WebAppUrl = "http://localhost";|
|private const string SiteUrl = "http://localhost/sites/Test";|
|private IPersonRepository repository;|
|private SPSite site;|
|public void SetUp()|
|site = CreateSite();|
|repository = new PersonRepository(site.RootWeb);|
|public void WhenAddingAPerson__ItShouldAddAPerson()|
|var list = site.RootWeb.Lists["Person"];|
|var person = AddPerson();|
|private SPSite CreateSite()|
|var webapp = SPWebApplication.Lookup(new Uri(WebAppUrl));|
|if (SPSite.Exists(new Uri(SiteUrl)))|
|var site = webapp.Sites.Add(SiteUrl, "contoso\\admin", "email@example.com");|
|private void CleanList(SPList list)|
|while (list.Items.Count > 0)|
|private Person AddPerson()|
|var person = new Person|
|Address = "Address",|
|BirthDate = DateTime.Now,|
|Name = "Name"|
|private void AssertCreation(SPList list, Person person)|
|var item = list.Items;|
Here we see a setup method that creates (or recreates) a site collection at every test run. To speed up the tests a bit, you can move that operation to a Fixture Setup, but that might mean that some tests pass or fail depending on the order of execution, so proceed with care. During the site creation we also enable one (or more) features that provision our sharepoint artifacts.
We then have the test method that checks that the Create method of the repository works fine by:
- Removing any item present on the list
- Calling the Create method with a valid person
- Checking (via standard object model) that was added an item to the expected list with the required properties.
In the same way one might test a Get method. First you clean the list, than you add the expected item (via SSOM), than you get it with your repository and assert that everything is fine. Try it doing it yourself and let me know if you have any problem.
Author: Maurizio Pozzobon
Maurizio has 5+ years developing solutions in the insurance industry. He is passionate about doing the right thing right, so he works in a tight loop with his clients to deliver the best solution possible.