SharePoint 2010 Test Framework

There is lot of buzz about SharePoint being the next big thing in market and that stands true when it comes to  creating simple, user-friendly site that provides all functionality that one could require just out-of-box. SharePoint brings in features, which help people work together more effectively. There was a time when SharePoint was thought to be useful for only intranet websites but this viewpoint has undergone a drastic change. Now-a-days there are a variety of internet websites which are built entirely on top of the SharePoint and make use of its built-in features. However, there still exists a need to customize SharePoint, for e.g. providing your organization’s branding to the basic SharePoint site, entrenching custom permissions on set of pages, defining templates for pages, custom lists etc. Such customizations of the SharePoint beget the need of testing.

The usual practice followed while setting up SharePoint farms is creation of authoring and rendering farms, and letting data flow from authoring to rendering, by the Content Deployment Job. While developing any functionality using SharePoint: creating sites, pages, setting page
properties, inserting web parts, setting web part properties, adding site columns etc. are all the pre-requisites to be completed exhaustively before testing can be started. SharePoint provides client side API’s for accessing SharePoint objects remotely, which are very well explained in this article. The main challenge in testing customized SharePoint site is the complexity involved in running automated test cases for customizes features which includes running multiple jobs like content deployment Job, variations Job, crawl ( in case you have search integrated) etc. There exists different ways to achieve this.

We should always remember that we are not testing SharePoint and its features. We are testing the custom features which we have built on top of SharePoint.

For any application, a test framework brings along with it many advantages viz. reduction in the number of testing hours, similarity in test case writing style and a definitive testing pattern. With SharePoint, there is thin line between what to test and what not to, as anything that interferes with OOB features, must be tested. In this article I will walk you through three approaches which we can use to test custom features in SharePoint, and their pros & cons.

1)     Client Object Model: This is very well explained by Eric White in his article. This can be used when we don’t require all SharePoint objects on client side.In other words, the Client Object Model is a subset of what we get in Server model. For e.g., user can create pages, folders, sites etc. by using this model but cannot run administrative jobs like Variation Jobs, Content Deployment jobs etc.

Advantages:

• Only 2 DLL’s need to be included in  testing solution on client side to use SharePoint objects (Microsoft.SharePoint.Client.dll & Microsoft.SharePoint.Client.Runtime.dll)
• It relies on SharePoint APIs for performing any action. You will not see any difference in activity performed by Commands used through Client Object Model & actions performed through SharePoint UI
• SharePoint OOB web services can also be used with this approach. SharePoint exposes web services, which can be consumed in project and can be used to practiceSharePoint objects remotely. A List of all web services is provided here. It can be consumed using PowerShell

Disadvantages:

• Central Admin tasks cannot be performed
• Client Object model provides subset of functionality of what we get on Server side

2)     Custom Web Services: In this particular approach, code resides on server side (either in form of C# code or PowerShell scripts) and remote calls can be made to the server to execute it. We can use web services to call a method residing on the server side and perform actions such as data creation, actions & verification.

Advantages:

• We can execute any command remotely as commands in actual will be executed on server
• Central Admin tasks can be performed
• Custom UI can be developed based on project needs and all tasks can be performed from Client.

Disadvantages:

• Web services use WCF and involve cross domain complications. There are high chances that you would end up spending a lot of time debugging the web services code rather than doing actual testing.
• If test cases demand running of CD, Variation job then maintaining them and running them in less time won’t be easy. If you keep your data creation, job runs and verification intact in a test case, you might end up running CD & variation jobs multiple times.

3)    Remote PowerShell:  This is 3-layered approach of performing actions on server side using PowerShell scripts remotely and takes advantage of Coded UI to perform other UI actions. PowerShell scripts which do all the tasks are executed remotely from client. These scripts also make use of SharePoint PowerShell API’s. 

• Data Creation – write C# code to call PowerShell scripts which are executed on server remotely. These scripts can reside on Client or on server based on ones need Actions – Integration of code with Coded UI for any action performed on site (button click, page re-direction, select/unselect etc.)
• Verification – Depending upon scenario one can opt from the options described in the above diagram.

Advantage:

• Smooth approach – easy to maintain.
• Full control over administrative tasks.
• Can run jobs only once for all test cases after creating data and then performing verification

Disadvantages:

• Strong coupling exists between parameters provided from client & inputs in PowerShell script.
• Might need to use CredSSP to allow users to securely send credentials of service account under which PowerShell scripts will run.

Code snippet for the Remote PowerShell model:

Page & WebPart are custom classes defined as per usage in project.

Data creation layer in project will contain code similar to the snippet below. This snippet includes making remote connections and invoking PowerShell script remotely.

Test cases will be written in such a way that a pair of test cases will actually represent full test case (DataSetUp & DataVerification). This is required as we don’t want jobs like Variation, CD & Crawl to run for each and every test case. So, based on the category, all DataSetup test cases will be run at one go and then all the jobs, following which verification test cases will be run. Verification tests are described in the below code piece.

To summarize, any of the above three approaches should be opted, based on the project requirements and what suits one’s need. Weighing out the advantages and exhaustively checking the current requirement frame, one can use the most appropriate model for the scenario, most aptly.