Microsoft Visual Studio 2012 provides complete record and play support through Coded UI Test for performing UI validations on Microsoft SharePoint 2013 applications. All the features provided by Microsoft SharePoint 2013 can be tested using Coded UI tests with few exceptions.
Recording and playing back on a SharePoint application is no different from recording on any webpage on Internet Explorer as internally the Coded UI Test IE plugin is being used. This blog assumes that you are familiar with Coded UI Tests and know how to record, generate code and play it back. For further details on how
to achieve the same, please take a look at the link provided. With Microsoft Visual Studio 2012 installed with VS Update 1, you can now test Microsoft SharePoint 2013 features on Google Chrome and Mozilla Firefox too with minimal changes. For learning more on testing on cross-browsers using Coded UI Test, please refer the link provided.
The following features of Microsoft SharePoint 2013 are supported by Coded UI Tests. There are a few handcoding changes are required to make few of the scenarios pass and they are described in a later section.
Feature |
Scenarios |
Support |
Ribbon Controls |
Do actions on ribbon controls |
Fully supported on IE. Supported on Cross-Browsers with few handcoding changes. |
Web Editing |
|
Fully supported on IE. Supported on Cross-Browsers with few handcoding changes. |
Calendar |
|
Fully supported on IE. Supported on Cross-Browsers with few handcoding changes. |
Tasks |
|
Fully supported on IE. Supported on Cross-Browsers with few handcoding changes. |
Community |
|
Fully supported on IE. Supported on Cross-Browsers with few handcoding changes with the exception of inserting a picture to the discussion. |
Microsoft Office 13 controls (PowerPoint) |
|
Supported on IE except playing PowerPoint Slideshow. Editing of slides and playing PowerPoint slideshow on Cross-Browsers is not supported. Rest of the scenarios are supported on Cross-Browser with few handcoding changes. |
Microsoft Office 13 controls (Excel) |
|
Supported on IE with handcoding |
Microsoft Office 13 controls (Word) |
|
Fully supported on IE. Supported on Cross-Browsers with few handcoding changes with the exception of inserting a picture to the discussion |
Silverlight Controls |
|
Not supported on both IE and Cross-Browsers. |
Visio controls |
|
Not supported on both IE and Cross-Browsers. |
Handcoding Changes
While recording and playback with Coded UI on Microsoft SharePoint 2013 is quite seamless, there are few scenarios which requires some minor changes to make the tests run seamlessly. Following are the list of handcoding changes that can be applied while testing a Microsoft SharePoint 2013 site.
- Working with Excel on Microsoft SharePoint 2013
- Cross Browser testing for Microsoft SharePoint 2013
1. Working with Excel on Microsoft SharePoint 2013
With Visual Studio 2012, you can record and playback on Microsoft Office 13 controls within Microsoft SharePoint 2013 as well. You can add, edit or delete any Office controls using the Microsoft SharePoint 2013 office Web App. While working with the Excel controls, few hand coding changes must be applied in order for the tests to pass.
If you are recording actions on an empty cell, then this action can be handcoded by double clicking on the cell and then performing a set text operation. This is needed because a click on the cell, followed by any keyboard action essentially activates the textarea within the cell. Simply recording a setvalue on the empty cell would search or the textarea which is in fact not present until the cell is clicked on. If you record a click followed by a setvalue, changing the Click to a DoubleClick in the generated code should do the trick.
Code Example:
Mouse.DoubliClick(uiItemCell,new Point(31,14));
uiGridKeyboardInputEdit.Text=value;
If you are recording on a non-empty cell, then it gets a little more complicated, this is because the moment you add text to a cell, a new <div> control gets added as a child of the cell which contains the text entered. The recorder records actions on the div which, before the text gets entered, doesn’t exist. In case case, follow the below steps:
//Go to cell initialization and make Row & Column Indexes as primary properties. These are in fact the best and most unique way to search for any cell.
this.mUIItemCell.SearchProperties[HtmlCell.PropertyNames.RowIndex]= "3";
this.mUIItemCell.SearchProperties[HtmlCell.PropertyNames.ColumnIndex]= "3";
// Find the "HtmlDiv" child of this cell, you can use “InnerText” and “Class” properties for this.
private UITestControl getControlToDoubleClick(HtmlCell cell)
{
if (String.IsNullOrEmpty(cell.InnerText))
return cell;
HtmlDiv pane = new HtmlDiv(cell);
pane.FilterProperties[HtmlDiv.PropertyNames.InnerText]= cell.InnerText;
// Class is an important property in finding pane
pane.FilterProperties[HtmlDiv.PropertyNames.Class]= "cv-nwr";
UITestControlCollection panes = pane.FindMatchingControls();
return panes[0];
}
//Code Double-click on HtmlDiv.
Mouse.DoubleClick(uIItemPane, new Point(31, 14));
//SetText on TextArea.
uIGridKeyboardInputEdit.Text = value;
Known Issues:
- Trying to record an action where we set some value to any cell, followed by an arrow key to navigate will fail to playback correctly.
- Editing cells will fail for cross browser playback.
2. Cross-Browser Testing For Microsoft SharePoint 2013
With Visual Studio 2012 with VS Update 1 installed, you can test Microsoft SharePoint 2013 sites on other supported browsers too (Google Chrome and Mozilla Firefox). While the playback on cross browser is quite seamless, you might encounter few failures which can be fixed with the handcoding changes given below.
- While playback on Chrome, you might encounter a scenario where the control is embedded inside another control and the playback on the control might fail with FailedToPerformActionOnBlockedControlException exception. For example, an image being embedded inside a hyperlink and trying to click on the hyperlink will
record the click on the image. The playback on Chrome on this action might fail with the above exception. If this is the case, enable CUIT_SELENIUM_CLICKCOORDINATEBASED environment variable to true by including the following line of code before the action. - Environment.SetEnvironmentVariable(“CUIT_SELENIUM_CLICKCOORDINATEBASED”, “true”);
- Make sure to include the following line of code at the end of the test to set back CUIT_SELENIUM_CLICKCOORDINATEBASED to false again by including the following line of code. Environment.SetEnvironmentVariable(“CUIT_SELENIUM_CLICKCOORDINATEBASED”, “false”);
- In certain scenarios, even when there are good search properties to search the control, the playback fails to find the control. This might be an issue with WaitForReady not being honoured. What might be happening is that the playback is trying to search for the control even before the control is completely loaded. To handle such a case, adding a small wait (Playback.Wait(int milliseconds)) before the playback searches for the control solves the problem.
- In few scenarios, the playback on cross-browsers fails to click on a control throwing FailedToPerformActionOnBlockedControlException exception. This usually happens when the control is embedded in another control. This can be solved by clicking on the parent of the control rather than the control itself. You can make this change by following steps:
- Open the UIMap.uitest file
- Select the action, in the UI Actions panel, which is throwing the exception.
- In the properties panel, select the UI Control property and change the UI Control to the parent control of the existing control. You can do this easily by selecting the parent of the control in the tree that appears after clicking the small inverted triangle at the end of the property.
- Save the UIMap.uitest file.
The above handcoding change is applicable for similar playback failures on Internet Explorer too.
0 comments