Why Remote Provisioning Helps Testing in Sharepoint

Introduction to Remote Provisioning

Before continuing with our series on testing in sharepoint we need to do a pit stop and introduce the concept of Remote Provisioning because it is quite useful when testing your application, in particular for the integration tests.

Remote provisioning is a concept introduced in Sharepoint 2013 and fundamental when working on Add-ins. It’s the suggested way to provision all your SHP artifacts (like Content Types, Fields, or Lists). It replaces everything that was deployed thought and Elements.xml and the Feature Framework.

OK, not everything, unfortunately the API isn’t on par on some things, but usually there are workarounds.

While remote provisioning an artifact you use the Client Side Object Model (CSOM) to programmatically create the artifact you need. This gives you the flexibility to build it imperatively and not declaratively (if you wish), but more importantly this prevents all the problems related to the feature framework like what happens when you have to update an existing object. If you have worked in SHP I have probably just summoned a few nightmares for you tonight, for something that should actually be quite simple.

If you want more information on doing remote provisioning I highly suggest you check out Office Dev PnP and it’s related provisioning engine, they provided a plethora of samples and helper methods to simplify doing remote provisioning and working with CSOM in general.

Why it helps

Let’s do a thought experiment:

Let’s say that you are testing a class in sharepoint, your test fails and you fix the class. Now you want to run the test… What should you do?

If you are used to doing TDD you might answer: “Just run the test”. Well doing it the traditional way you would have deployed your application’s DLLs with the same WSP that provision your artifacts*. This means that the DLLs are in the GAC and that means that the old version will be used instead of the one you just fixed.

So your test will keep failing and if you don’t realize it you could be wasting a lot of time trying to figure out why that happened.

To fix this you either have to deploy the new version (which is slow) or you retract the WSP so that your test framework can run from the local (and recent) copy. The problem is that if you retract the WSP all your artifact are removed from the sitecollection and you might get failing tests.

By doing remote provisioning all your artifacts deployed separately to the WSP and so you can safely retract it and keep working in a fast RED-GREEN-REFACTOR cycle. Also this way the deployment of the WSP is way faster.

*For those that don’t know SHP development this is like deploying your database in the same package that deploys your application’s DLLS

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.