Coded UI in SharePoint 2013 – An introduction

Introduction

Coded UI testing can be a powerful method of ensuring the functional correctness of your application. UI tasks such as clicking buttons, entering text, selecting values and observe the outcome can become very tedious for testers. By automating these tasks, testers can focus on what is really important for your application: finding bugs that are not trivial to find.
Coded UI testing should live next to other testing methods of your application, such as unit testing, performance testing and manual testing (for those tests, which cannot be automated).

In this post, I will demonstrate how to set up a simple Coded UI test for an on premise SharePoint 2013 environment. In later posts I will show how to enhance the robustness of Coded UI tests.

Prerequisites

  1. An on premise SharePoint 2013 environment (I am using version 15.0.4420 RTM installed on Windows Server 2012 XXX)
  2. At least Visual Studio 2012 Ultimate (I am using Visual Studio Ultimate 2013 12.0.21005.1 REL)
  3. A SharePoint 2013 site collection based on the developer template (I created a site named “GamesCollection”)

Scenario

I have created a new SharePoint solution, which contains a GamesList site feature. Upon activation of this site feature, a list is added to the site.
Upon deactivation of the feature, the list is removed from the site.
What is important to consider is that with Coded UI testing, we want to test our custom code and not SharePoint out of the box functionality.
When working with SharePoint, the separation between out of the box functionality and custom code is not always clearly visible.
Try to avoid over-testing SharePoint out of the box functionality by asking yourself the question: “Am I testing out of the box or solution specific functionality?” for each test case you create.

In this example, adding the list to the site by activating the feature and removing the list from the site by deactivating the feature is considered solution specific functionality. Checking if the custom list contains the columns as specified in the solution is also considered solution specific functionality.
Creating new items in the list however, is considered SharePoint out of the box functionality.

Steps

  1. Create the CodedUI project
  2. Record steps
  3. Run the recording
  1. Create the CodedUI Project

In Visual Studio, the Coded UI Test Project template can be used to create the project.

Figure 1: Create new coded ui test project

No actions have been recorded yet, so select the first option and click on “OK”.

Figure 2: Generate Code for Coded UI Test

After renaming the Visual Studio autogenerated test class and method, we are almost ready to initiate a recording.
Open internet explorer and browse to the site collection on which you would like to test.

Figure 3: Navigate to root site collection

  1. Record steps

Notice the Coded UI Test Builder in the lower right corner. Press on the red recording button to start the recording.

Figure 4: Coded UI Test Builder

Navigate to the site features page, by specifying the URL directly in the address bar and press enter.

Figure 5: Site settings

You could also click on the site settings icon -> site features, but it is possible to encounter stability issues on the site settings icon, causing your test to fail. Later posts that focus on getting the recordings more robust will not use the settings icon at all.

Notice that when deploying the custom GamesCollection solution to SharePoint 2013, the feature got activated by default, so the List is already present on the root site of the GamesCollection site collection.
Deactivate the GamesCollection List feature.

Figure 6: GamesCollection List feature

Click on the pause button.

Figure 7: Pause button

Click on the stairs symbol next to the pause button. You should see something similar to the following:

Figure 8: Recorded Actions

Click on the generate code button (rightmost button), give the recording a name and click on “Add and Generate”.

Figure 9: Generate code

Click on the record button again and navigate to the (nonexistent) URL of the GamesCollection list.

Figure 10: Navigate to GamesCollection list 404

Generate code for this action, and name the method for example: “NavigateToGamesCollectionListURL”.

Now, we need to somehow verify (assert) that we get a 404 page and that this is expected behavior, since the list should be removed.

Notice the target button in the Coded UI Test Builder that allows us to add assertions to what can be seen in the UI.

Figure 11: Add assertions

While pressing and holding this button, drag it to the IE title bar and release. You will see something similar to the following:

Figure 12: Add assertion 404

Click on “DisplayText” and on “Add Assertion”.

Figure 13: Add 404 assertion based on DisplayText

Click on OK in the “Add assertion for: DisplayText” dialog.

Figure 14: Add assertion for DisplayText dialog

Generate the code and name the method. For example: “Assert404”.

  1. Run the recording

Navigate back to the site collection root site home page.

Figure 15: Site collection root site home page

When switching to the coded UI test project in Visual Studio you should notice the following three methods available:

Figure 16: Recorded action methods

Keep IE open and focused on the homepage before running the test. In later posts it will be shown how to start and stop browser sessions between tests.
Run the coded UI test, by either right clicking it in Test Explorer or pressing the shortkey combination CTRL+T, CTRL+R (debugging). I prefer running the tests in debug mode, since it will provide you more information when the test fails.

Figure 17: Run the coded UI test

The test will fail, because the GamesCollection List feature was deactivated before (during the recording). It will click on the activate button (since this is the same button as the deactivate button) after which it expects a new page for confirmation of deactivation. This page will not show, because the feature has just been activated instead of deactivated.
For now, abort the test and run it again.
Notice in the Test Explorer, that the test succeeds.

Figure 18: Test succeeded

Conclusion

Coded UI tests can be very useful when testing UI elements of your custom solution in SharePoint. The tests focus on what the end users actually see happening in SharePoint.
Coded UI test recordings are easy to create and execute, but additional effort is needed to maximize robustness of the recordings.

3 thoughts on “Coded UI in SharePoint 2013 – An introduction

Leave a Reply