Partager via

SharePoint Test Automation using CSOM (Client Side Object Model)

  • Article

Abstract:

Testing of SharePoint applications including unit testing is one of the popular topic of debates. This puts more onus on the QA/Test teams to test SharePoint applications even more extensively. You can of course automate SharePoint’s GUI using Visual Studio Coded UI tests, which has an excellent support for SharePoint. Automating SharePoint’s GUI is not very different from automating any other web application, where user actions and interactions are recorded and played back. This is a good approach for functional testing or black box testing but we are really not focusing on SharePoint related components in this case. In this article, we would like to propose an alternative approach that can be much more effective when you are specifically interested in testing SharePoint components without over relying on end-to-end GUI testing, which can be fragile due to high maintenance effort and generally happens too late in the game. APIs based automation is also much faster than running GUI based automation tests

The suggested approach is to leverage SharePoint Client Side Object Model (CSOM) API’s and our CSOM add-in published on Visual Studio Gallery to help improve SharePoint test coverage. The add-in supports SharePoint 2010, SharePoint 2013 and Microsoft SharePoint Online. The advantage of using approach is that this code doesn’t need to run on SharePoint server and it is executed from any client machine, provided the user has the required permissions on the SharePoint site under test. This approach would help the development and test teams in improving the quality of code and minimize SharePoint related deployment and configurations issues, which are major pain points today. This can also be very handy in validating content and features in SharePoint upgrade and migration scenarios. Testers can write test-cases even no application is available, if proper design document is available then that can be refer.

We will provide a walk-through of this approach and how QA/Test teams can use or extend it to automate their SharePoint test scenarios.

  • You can directly write your automated test by writing managed code to interact with SharePoint CSOM API’s but or leverage our CSOM add-in that consists of common libraries that are built on top of SharePoint CSOM API’s to accelerate SharePoint automated testing. These helper methods address generic SharePoint test requirements, which we have derived from our learning of executing SharePoint test engagements, with the intent to verify various properties and attributes of SharePoint objects.

  • You will also learn the other benefits of using SharePoint CSOM APIs for test activities like test data generation, build verification testing and deployment testing

Pre-Requisites

It is assumed that the audience will have basic knowledge of following tools and concepts for using this approach

  • Visual Studio 2012/2013/2015, C#.Net, Unit Tests
  • SharePoint 2010/2013/2016/SharePoint Online

Overview of SharePoint test requirements

  • List items/Schema Validations like column its type and other properties of lists.
  • Library items/Schema Validations like column its type and other properties of library.
  • Site columns and its properties like its type, is it required filed or not, validation, default values etc.
  • Content types and its columns validation.
  • User groups, users and permission validations.
  • Site hierarchy, Web parts and Pages validations.
  • Test data generation for SharePoint objects like List, Libraries etc.

Using SharePoint CSOM’s Visual Studio Add-in to test SharePoint applications:

  • Download our CSOM Add-in or Go to Visual Studio IDE  -> Tools -> Extension and search for “SharePoint Test Automation” Create a Test Project in Visual Studio 2010/2013
  • Add reference to all DLLs downloaded from the add-in to the test project.
  • Add Name Space for SharePoint Client API and Test Automation Framework
  • using System; using System.Text; using System.Collections.Generic; using System.Linq; using Microsoft.VisualStudio.TestTools.UnitTesting; //Name Space for SharePoint Client API using Microsoft.SharePoint.Client; //Name Space for Framework using Test.Automation.SharePointCOM.Verification;
  • Use the framework classes and initialize the SharePoint Application Under test: //Adding Reference to the class which have verification method

SPVerification verifySite;

String TestSite, Domain, UserName, Password;

 

 

//Function for setting up the SharePoint Site under Test

[TestInitialize]

public void SetUp()

{

TestSite = "https://SharePointWebApp/sites/SiteCollection/TestSite";

Domain = "MyDomain";

UserName = "SiteAdmin";

Password = "Password";

verifySite = new SPVerification();

//Setting the SharePoint Site Under Test Assert.IsTrue(verifySite.SetSiteUnderTest(TestSite, UserName, Password, Domain, testContextInstance));

}

 

  • Add a test method in the unit test file to validate a list on a SharePoint Point site (In the framework each method return a true or false which should be used with asserts to check the pass or fail status of a test) /*Test Method to Verify the Expected list on a SharePoint Site mentioned in the SetUp (In test initialization method)*/ [DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV", "C:\\TestData\\TestSite\\SP-Lists.csv", "SP-Lists#csv", DataAccessMethod.Sequential), TestMethod]

public void VerifySPLists()

{

string ListName = testContextInstance.DataRow[0].ToString();

Assert.IsTrue(verifySite.VerifyLibraryExists(ListName, testContextInstance));

}

  • Run the test
  • Analyze the result (Framework uses the Test Context to log the results, which is useful to log the bugs and understand where the issue is):

[caption id="attachment_25" align="alignnone" width="624"]Execution Results Execution Results[/caption]