Introduction

Most user interface (UI) technologies arrange their UI elements, such as buttons, textboxes and dialogs in a tree. By navigating this tree, the user interface of an application can be reduced to a logical view rather than just the raw bitmap/pixal data which makes up a screenshot.

In the example above, an example “save dialog” is deconstructed into the separate entities that make up the entire dialog. Each element in the user interface can have much information associated with it, such as:

• AutomationId, for instance, the OK button may have the AutomationId “overwriteOkButton”.
• Value, for instance, “OK” for the OK button.
• ControlType, the buttons are marked as buttons, the text label is marked as a label, and so on.

All these bits of information are referred to as identifiers in the Windows Automation tool, because they are used to identify elements in the user interface, for instance, to identify the button to click.

For instance, in the example above we could use Value = ‘OK’ to identify the OK button.

When writing a user interface test using the Windows Automation Tool, the element to interact with – for instance the element to click – must be identified in the script.

To identify user interface elements, selectors are used to describe the path that the Windows Automation tool must take to navigate the user interface tree to the element to interact with.

Selectors are lists of identifiers along with an expected value, for instance: Value = ‘OK’ is an identifier (Value) with an expected value (OK).

In the “Save dialog” example above, the selector to identify the OK button would have to have three selector parts:

• One identifying the dialog
• One identifying the content part of the dialog
• And one identifying the OK button.

In reality, selectors are usually deeper, depending on the complexity of the user interface under test, but for this simple example a selector for the OK button could be:

• AutomationId = ‘OverwriteDialog’
• AutomationId = ‘Content’
• Value = ‘OK’

Sometimes parts of the path to an element cannot be described in a way which makes the test robust enough, for instance a selector containing AutomationId = 312131 looks like something which is generated dynamically by the application, and something which will change the next time the application is run.

In this case it is possible to simply just put a wildcard * (star) on that position of the selector. In the example above, we could ignore the content element, by using this selector instead:

• AutomationId = ‘OverwriteDialog’
• *
• Value = ‘OK’

This will make the Windows Automation tool try to search all elements at that level in the tree for a child where the Value = ‘OK’ identifier matches.

Furthermore, it is possible to ignore several levels of elements in the user interface tree by using the ** (double star) wildcard – this wildcard is referred to as the “all descendants” wildcard. For instance:

• **
• Value = ‘OK’

This will make the Windows Automation tool search for any element where the Value = ‘OK’ identifier matches, no matter where it is in the tree.

Wildcards can be combined and used multiple times to create short paths for very complex user interface trees, for instance:

• **
• AutomationId = ‘ScriptEditor’
• **
• Value = ‘Edit’

This selector will first find any elements matching AutomationId = ‘ScriptEditor’ in the user interface tree, and then from each of those elements, look for any element which matches the Value = ‘Edit’ identifier.

By default, the Windows Automation tool will search the entire tree to make sure that only one element matches the entire selector, this is done to make sure that the Windows Automation tool will not accidentally interact with an unwanted element.

All Windows Automation tool steps/methods which interacts with an element needs to have the selector for that element defined.

In the example above, a “Click” step for clicking the Windows start button has been inserted.

It is, of course, possible to change the selector manually using the “Add/Remove/Up/Down” buttons and the keyboard, but it is much easier to use the “Select (push and drag)” and “Select (in 5 seconds)” buttons shown above the selector.

Both buttons will change the selector to reflect the element under the mouse button, but work in two different ways:

• Select (push and drag) – here the element is selected by pressing and holding the left mouse button down on the button, and then dragging the mouse to the element which the selector should refer to and then releasing the left mouse button.
• Select (in 5 seconds) – can be used to click elements which hide themselves when another application is clicked – for instance to click a sub menu-item. So the element is selected by clicking the button, and then, within 5 seconds, moving the mouse to element which the selector should refer to. 5 seconds should be enough to open any menu items to point to a sub menu-item.

It is easier to try this than to read about it, so experimenting is usually a good way to get acquainted with the Windows Automation Tool’s selector.

In both cases the element under the mouse is highlighted using a transparent magenta rectangle.

When the “Use selector dialog” button is active/highlighted (by default it is), then the Element Selection Dialog is shown after an element is selected.

Using this dialog, the script writer can improve on the selector which the Windows Automation Tool can find to the highlighted element.

The Element Selection Dialog will examine the user interface tree to find the identifiers of the elements, and list the identifiers which results in a unique selector.

In the screenshot above, the Element Selection Dialog is showing the possible selectors which point to the “File Explorer” icon on the Windows start menu.

The script writer can then look at the individual elements in the selector and select the relevant identifier to use, the script writer can also choose to use the * wildcard to ignore parts of the selector.

After the Element Selection Dialog has found the possible identifiers for each of the element selector elements, it will try to find even shorter selectors using the ** (all descendants) wildcard. If any wildcard selectors are found, they will be shown in a new list in the dialog.

In the screenshot above, the Element Selection Dialog has found a very short selector which uniquely identifies the element, the script can use this step:

Instead of this step:

Using the shorter selector has the potential of making the test more robust against changes to the user interface, for instance, if a button is moved in the user interface tree. But the Element Selection Dialog can only help to suggest unique identifiers to an element, only the script writer can tell whether a selector is good or bad using knowledge about the application under test.