Our vBulletin migration is complete.
Welcome vBulletin users! All content and user information from the Micro Focus Forums (vBulletin) site has been migrated to this site. READ MORE.

Improving the Testability of Your Applications

ernst_ambichl Absent Member.
Absent Member.
0 1 4,991

To be able to reliably identify UI controls, Silk Test, like any other UI automation tool, relies on adequate identifiers that the application exposes for its UI controls. Unlike other automation tools, Silk Test provides great flexibility and power in the way it can identify UI controls.  Not only can Silk Test use any declared properties for any UI control class, it also can create identifiers (which are called locators with Silk Test) using the hierarchy of UI controls meaning that it chooses the most appropriate items and properties to identify an UI object along the UI control tree. A major advantage in working with hierarchies is that Silk Test can also exclude hierarchies for object recognition so that you can exclude controls along the hierarchy. Being able to exclude dynamic numbers of controls along the UI control hierarchy makes Silk Test object recognition very robust against changes in the application where intermediate grouping controls are introduced that change the hierarchy of the UI control tree (e.g. formatting elements in Web pages).

For additional information, see Creating Stable Locators


Although hierarchies and especially dynamic hierarchies provide a good means to create unique locators for UI controls that do not expose meaningful properties to uniquely identify them, it still is a work-around for applications with bad testability. Applications providing good testability should always provide a simple mechanism to identify UI controls uniquely.   


Stable Identifiers

A stable identifier for a UI control means that the identifier for a certain control is always the same – between invocations of the control as well as between different versions of the application itself. A stable identifier also needs to be unique in the context of its usage, meaning that there is not a second control with the same identifier accessible at the same time. This does not necessarily mean that you need to use GUID-style identifiers that are unique in a global context. Identifiers for controls should be readable and provide meaningful names. Naming conventions for these identifiers will make it much easier to associate the identifier to the actual control.


Is “Caption” a Stable Identifier?

Very often test tools are using the caption (the text in the UI associated with the control) of an UI object as the default identifier and you may think that the caption provides a good way to identify the control. But there are several drawbacks of using the caption of a control for identification:


  • It’s not really stable: Captions are changing frequently during the development process. Often the UI is reviewed (and captions get changed) by a documentation team at the end of the development process. This prevents introducing UI testing early in the development process as the UI is not stable (you certainly heard this statement before).
  • It’s not unique: captions are often not unique. How many “Ok” buttons does you application have?
  • There is no caption: Many controls (and even the more complex one) are not exposing a caption, so you need to use another property for identification.
  • What when localizing the app is needed?  Using captions for testing localized applications is cumbersome, as you need to maintain multiple sets of captions (for each localized language one) as well a complex script logic where you dynamically can assign the different “localized” versions of the ­captions.  

To improve the testability of your application one of the simplest and most effective practices is to introduce stable control identifiers and expose them via the existing interfaces of the application.


UI Technologies with Custom Properties

Many UI technologies provide a mechanism that allows them to extend the set of predefined properties of UI controls with custom properties. These custom properties can be used by the developer to introduce stable identifiers that uniquely identify the control. Silk Test can access custom properties of UI controls and also can use these custom properties to identify/find UI controls.

Web Applications

HTML defines a common attribute “ID” that can represent a stable identifier. The definition says:


The “ID” attribute uniquely identifies an element within a document. No two elements can have the same “ID” value in a single document. …


But in many cases – especially with AJAX applications the attribute “ID” is used to dynamically identify the associated server handler for the HTML element/control, meaning that the attribute “ID” changes with each creation of the Web document. So it is absolute useless as a stable identifier. One example using this pattern is the Google Widget Toolkit (GWT) where” ID” often holds a dynamic value which changes with every creation of the Web document:


Example GWT: ID = ’gwt-uid-<nnn>’ where <nnn> changes frequently


For additional information, see Creating Stable Locators


Hence is the attribute “ID” often not suitable for identifying Web UI controls. Often a better alternative is to introduce a new, custom HTML attribute that is exclusively used to expose UI control information to the test automation tool.


Custom HTML attributes are ignored by browsers and so do not change the behavior of the application but are accessible through the Browser’s DOM. Silk Test allows you to configure the property/attribute that you want to use as the default attribute for identification even if it's a custom and not a predefined attribute of the control class. To set a custom attribute as the default identification attribute open the dialog “Options” in menu “Tools” in Silk Test Workbench: 


Figure 1: How to configure a custom attribute to be used as the default identification attribute


For the developer it’s as easy as adding an additional HTML attribute to the Web element.

Original HTML code snippet:

  <IMG src="http://abc.com/xxx.gif" width=16 height=16>

HTML code snippet augmented with a custom HTML attribute “AUTOMATION_ID” :


  <IMG src="http://abc.com/xxx.gif" width=16 height=16>


Java SWT Applications

Very similar to Web applications can you add a custom property (called “application defined property” in SWT) to an SWT control. As a developer of a SWT application you only need to add the custom property using the “setData” method of the widget:

Combo param1Combo = new Combo(commandGroup, SWT.NONE);
param1Combo.setData("AUTOMATION_ID", "AID_param1Combo");


When configuring the custom attributes Silk Test will use the custom attribute to construct a unique locator whenever possible. Locators will look like:

Locator for Web: …//DomLink[@AUTOMATION_ID=’AID_Login’]


Locator for SWT: …//ComboBox[@AUTOMATION_ID=’AID_param1Combo’


UI Technologies with Special Automation Properties

Other UI technologies provide already special predefined “automation” properties that shall be used to expose stable identifiers for UI controls to the test automation tool.

WPF Applications

WPF applications use a defined property “AutomationProperties.AutomationId” to specify a stable identifier for the WPF control:

<Window x:Class="Test.MainWindow"
        Title="MainWindow" Height="350" Width="525">
    <Button AutomationProperties.AutomationId="AID_buttonA">The Button</Button>


Silk Test automatically will use this property for identification in the locator:




WinForms Applications

WinForms applications use a defined property “automationId” to specify a stable identifier for the WinForms control:

 Figure 2: Visual Studio Designer – Setting Property “automationId”


Silk Test automatically will use this property for identification in the locator:

Locator: /FormsWindow//PushButton[@automationId='btnBasicControls']


Flex Applications

Flex applications use a defined property “automationName” to specify a stable identifier for the Flex control:

<?xml version="1.0" encoding="utf-8"?>
<s:Group xmlns:fx="http://ns.adobe.com/mxml/2009" 
         xmlns:mx="library://ns.adobe.com/flex/mx" width="400" height="300">
      <s:Button x="247" y="81" label="Button" id="button1" enabled="true" 
        click="button1_clickHandler(event)" automationName="AID_buttonRepeat"/>
      <s:Label x="128" y="123" width="315" height="18" id="label1" 
        verticalAlign="middle" text="awaiting your click" textAlign="center"/>




Attention: In the case of Flex the special automation property “automationName” is mapped in Silk Test to the locator attribute “caption”. Is the Flex property “automationName” specified, Silk Test will always map this property to the locator attribute “caption”. If it’s omitted, it will map the property “ID” to the locator attribute “caption”.



Using special automation properties for the identification of UI controls has several advantages compared to using the available, defined properties like caption. Being able to establish stable identifiers in the application code and expose them through either custom properties or defined automation properties leads to easy understandable and maintainable test automation scripts allowing you to start with your test automation early in the development process.

Not all test automation tools allow you to use custom properties to identify UI controls. With the flexible locator strategy of Silk Test, you can configure the properties used for identification.

1 Comment
Suresh5 Absent Member.
Absent Member.

Thanks for the nice article. We are currently using Micro Focus Dialog Systems for one of our business applications, and we are running into bit of a challenge with the UI Automation. does your Silk suite support Dialog Systems UI as well? I can see that the SilkTest supports Web based applications, WPF, Windows Forms and others... but what about Dialog Systems?

Dialog Systems doesn't seem to be following proper protocol here... some of the developers set the name property for controls, but at run time, that name property doesn't get translated to automation_id similar to Windows Forms. I appreciate any comments or workaround.



The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.