How does “Coded UI test” finds a control ??

How does “Coded UI test” finds a control ??

Coded UI tests allows user to capture actions and generates property validations on the controls in the application. In order to do functional testing on the application, Coded UI test needs to playback all the actions that are captured and perform validations on the UI objects in the application interface. So, Search for controls forms the base for all the actions and validations done by Coded UI tests.

In order to find the control in test execution phase, Coded UI test captures some set of properties on the control and name them as “Search Properties” and “Filter Properties”. Each instance of these is a Name-value pair, with Name being the Property-Name and Value being the actual value of the property during the time of the capture.

Search for a control always starts from desktop. Lets take an example of a control whose search properties and filter properties are captured

Description

From the code, we will be able to get all the properties that are associated with the control under test from the control object ( mUIEmailEdit ). When the search for the control starts ( explicit by Find() or implicit by any usage of the control in actions or property validations ), it starts finding the controls under the Container element of the control ( someAncestorControl ).

Search in Coded UI test is a Breadth-First which compares each of the controls in the traversal for the match of the properties given in the code.

First pass of the Search is done for the match of All properties given in SearchProperties list. Basically this can be referred as AND Condition of search properties. In cases, where the results of the search using SearchProperties finds exactly one control or doesn’t find any control, Coded UI test skips using the Filter Properties (even if is defined in the code) because of the 2 cases,

1. There is exactly one control, so there is no need to apply filters.

2. There are no controls to apply filters.

But, in cases where the list of SearchProperties is not good enough to find the exact control, Coded UI tests uses the filter properties (one by one) till it finds One exact match. Basically this can be referred as Ordered Match.

In remote cases where Search using FilterProperties also results in more than one control, the First match is returned as the resultant control.

Example

Lets take the instance of search for the code written above

1. Search starts at the “someAncestorControl” control as it is specified as the ancestor for the control to be found.

2. At every traversal, we match the properties of the current control “X” with the search properties mentioned in the code. Let say we have a list of controls (X1, X2 and X3) under the container’s hierarchy that matches the properties.

3. Now we need to nail down the search to one control. From the list (X1, X2 and X3) , we check for the match of 1st Filter property ( HtmlEdit.PropertyNames.LabeledBy ). Let say the list now trims to (X2 and X3). In case of no match , we skip this filter property and keep using the next filter property for search.

4. We continue #Step3 with the following filter properties (one-by-one) till the list of resultant controls trims to 1 or till all the filter properties compared.

Workflow of Search

Technology specific data

1. Search for Web controls : Both SearchProperties and Filter Properties are supported.

Choice of SearchProperties

Each technology has a limited set of properties that can be used for search via Coded UI tests. So, Coded UI tests chooses only the properties exposed by the technology as SearchProperties. These are chosen by targeting a good trade-off between robustness and performance.

For instance, the Web technology exposes many properties including all the attributes of the controls rendered in the page, whereas .Net controls’ accessibility exposes only a sub-set of the properties via accessibility.