One of the major problems with SharePoint development is that the framework is not designed with testability in mind. It is not easy to replace the SharePoint object model using Mocks/ Stubs which makes practices like unit testing more difficult in SharePoint development.
The main focus will be to use a combination of best architectural practices and isolation frameworks to achieve best results to do Agile in SharePoint. For e.g. isolating SharePoint calls using a Repository pattern makes it easy to mock a repository object in the above layers to isolate SharePoint object model. Building SharePoint solutions using XP techniques helps the teams in faster development, predictable deliveries, better quality, less stress and happy stakeholders
Repositories act as mediators, or interface layers, between different parts of an application. Making use of the repository pattern the SharePoint object model can be exposed using a and repository which will be responsible for using the SharePoint API for querying and updating SharePoint list items.
By using a combination of Specification and data mapper pattern with Repositories will allow the team to centralize the SharePoint list access logic and conversion of types. This provides a simplified access mechanism of list data and provide a layer of abstraction that makes unit testing with emulators/mocks much easier
Separating the logic for the UI from the code that handles user events, fetching data from repositories by using an implementation of MVP allows developers to replace the actual view with a mock object for unit tests.
With the availability of SharePoint Emulators the isolation of the SharePoint API is much easier compared to the old way of isolating using the Moles or Fakes framework.
In order to incorporate emulators into existing tests you should wrap the relevant code in a SharePointEmulationScope, which accepts EmulationMode enum as a parameter. It is enabled by default which in turn performs run time interception of all Microsoft.SharePoint.dll calls.
[TestCategory("Data access layer tests")]
[Description("Test to verify the data mapper functionality")]
public void BuildFromSPListItem_should_create_a_new_object_with_populated_values()
using (new SharePointEmulationScope(EmulationMode.Enabled))
var dataMapper = new MyObjectDataMapper();
const string customDescription = "Custom Description";
using (var emulatedSite = new SPSite("http://localhost:8081/MySite"))
var listId = emulatedSite.RootWeb.Lists.Add("MyList", "Custom list", SPListTemplateType.GenericList);
var list = emulatedSite.RootWeb.Lists[listId];
var listitem = list.Items.Add();
listitem["Title"] = "mytitle";
listitem["CustomDesc"] = "Custom Description";
var myObject = dataMapper.FromSPListItem(listitem);
Assert.IsTrue(myObject.CustomDesc == customDescription);
Smoke tests are quick, lightweight test or set of automated tests, that confirm that the basic functionality of the sites are working as expected. We use the smoke tests to verify whether the basic standards of internet sites are adapted and are working as expected in all the environments. The smoke tests are executed from a set of configuration files that specify the details of the sites and environments to run against.
By having proper smoke tests, the team can ensure that the site works with the basic functionalities after every upgrade or patches are done on the farm.
The team also creates a set of UI driven automated tests that cover the functional testing of the UI controls. This helps us verify that the whole application including the user interface is functioning correctly. Teams create Coded UI tests that help remove the need for manual regression testing of a functionality. The Coded UI tests simulates the user experience of clicking through the UI controls to verify things are working correctly.