Test Automation - VS 2010 Coded UI - Customization Techniques for Win Applications

Introduction

A.   Creating a Coded UI Unit Test Method for Calculator Application

For information on the basics as to how to create Coded UI Test Method, record the UI Actions and adding assertions please refer to the following MSDN link

http://msdn.microsoft.com/en-us/library/dd380755.aspx

B.   Customize the Coded UI Recorded Test Method

Let’s consider the window Calculator Application and see the ways to customize the same.

1.    Create a C# Test Project and Add a CodedUI Test Item.

2.    Record the UI Actions for the Following Scenario

A.    Launch the Calculator Application.

B.    Perform an Addition Operation by clicking on  ‘4’ , ‘+’, ‘6’ and ‘=’ buttons.

C.    Add an Assertion for the Output (10).

D.    Close the Calculator Application

3.    Save the Auto Generated Code to the Coded UI Test File.

Initial Observations and Understanding

For the Scenario we recorded the VS Test Editor generates the following hierarchy of UI Objects in the UI Map file.

The code generated was based on how the UIA framework (on which the coded UI Works) Visualized the Calculator Application. Here it visualized the Calculator Application as having One Parent Window (UICalculatorWindow) and many Child Windows. Each of these Child Windows in turn encapsulates a Control Type (button, Text).

B.1 Where and when is Customization needed?

B.1.1 Customization Scenario 1: Recalculating the UI Control’s coordinates for a smooth playback.

When we take a close look at the following RecoredMethod, we can observe that the VS Test editor in fact recorded and hardcoded the screen coordinate  of the UI controls and the Mouse.Click () method uses the same to perform the Click operation on the UI.  This one at times may result in playback failure and the reasons can be one of the following

1.       It’s unlikely that the coordinates of the UI Controls remain same during the playback phase.

2.       The Coded Test UI recording done on one Machine and replayed on various Machines with different display resolutions.

The code generated was based on how the UIA framework (on which the coded UI Works) Visualized the Calculator Application. Here it visualized the Calculator Application as having One Parent Window (UICalculatorWindow) and many Child Windows. Each of these Child Windows in turn encapsulates a Control Type (button, Text).

Hence it’s always safe to re-calculate the coordinates of UI Controls at runtime. For this the VS team Editor has an in build method - GetClickablePoint (), which can be used to recalculate the UI Control coordinates on the target Machine.

The above Code can be modified as follows

B.1.2 Customization Scenario 2: Reusing the recorded UI Controls Information and accessing their Sibling UI Controls

Let’s revisit the UI Controls Hierarchy as shown below.

On a Closer look at the UI Button Controls references (UIItem4Button, UIAddButton, and UIItem6Button); one can term them as siblings since they have almost identical parent hierarchy (UICalculatorWindow -> UIItemWindow).  Hence the idea here is, to programmatically modify the search properties of the existing recorded UI Controls and access the other non-recorded UI Controls.

For Example user wants to perform Addition operation 7 + 9 instead of 4+6.

In this case would we be inspecting the 7 and 9 Button Controls and add the information to the UIMaps? The answer is absolutely No. we can simply reuse the existing recored UI Control to achieve this feat.

Let’s take a look at the search properties of Button “4” and Button “6” as recored by the UIA Framework

On a close Inspection we can see that both the Button Controls almost have identical Search Properties and differ only by Name property.  Hence, we can assume that even the Button 7 and Button 9 will almost differ by their Name property only.

Using the crosshair on the “Coded UI Test Builder”, inspect the Name property value for Button 7 and 9 and the following are the corresponding “Name” property values.

Modify the Above Addition Operation as follows

At the start of program execution, the variable “UIItemGenericButton” is referencing to Button “4” (UIItem4Button Class property has the initial search properties of Button 4). Latter we are changing the search property of “UIItemGenericButton” variable (Changing the Name property Value to 7) so that “UIItemGenericButton” now refer to Button 7 and then we perform the click operation on Button 7. Further we are once again change the search property of “UIItemGenericButton” so as to refer to button 9.

Advantage:

1.       The advantage here is that rather recording the UI Control information for the new to be inspected Controls; we can reuse the existing recored UI Controls.  More over this would help us keep the UIMap file simple and understandable.

2.       This particular Customization is very helpful in web application where on a form we many have 10-15 controls whose value need to be set or modified.

3.       At times we many need to change more than one property of associated UI Control, so that UIA Framework can uniquely identify the Control on UI.

B.2 A sample Customized, Data Driven Coded UI Test Method

Using the above Customization technique (section B.1.2 ), Lets  customize  the entire  CodedUI Test method  to make it  generic  so as to support various other operations (Subtraction, multiplication, division) and for different values .

To achieve we need to perform the following steps

1.       Add a .csv File to the Test Project and name it as “Input.csv”. We will use the .csv file as data source for the CodedUI Test Method.

Open the Input.csv file and input the following Test Data.

2. Since we know that the Name Property is sufficient to uniquely identify the button controls on Calculator Application, we are specifying the same in our input data.

3. For Example to perform operation   “ 2 + 4 “  we need to input the  “2”,”Add”,”4”,”Equals” which are   the   Name Property of Button 2, Button +, Button4.

4. For Validation purpose, we are also specifying the Result in our input Data.

Modify the CodedUI Test method as Follows

1.       In the CodedUI Test Class, we create a new Test Method (CalcOperations ) and added

The “DataSource” and “DeploymentItem” attributes to make the Input.csv as the Data Source for our Test Method.

2.       We created a reference of type WinButton and made it initially refer to the UIItem4Button Class Property. 

3.       Latter, based on the Input Data (Param1, Operator1, Param2, Operator2) we are modifying the search properties (Name Property) so as to make the WinButton refer to the UI Control we desire.

4.       In the end we are validating the Output( which can be read via the WinText Object  ) with the one we are expecting(Result).

Conclusion

Customization of the Coded UI Test Methods is necessary for minimizing the playback failures. It even helps in keeping the auto generated Code simple and understandable.