If not properly designed, user interface (UI) tests can be slow and prone to failure, or “fragile”. But your tests can be stable, even when the UI changes. One of the most important factors in designing a UI test for stability is the method used to identify UI elements including text, form fields, buttons, scrollbars, and other controls.
Understanding the basics
A typical UI (whether for desktop, mobile, or web application) is organized into series of containers nested one inside the other. To locate a given UI object, an automated test uses attributes such as the object ID, class, name, and the path to locating it within its container. Some locators are inherently more stable than others.
Watch the video below for a demonstration identifying UI objects in Ranorex Spy. As you watch, notice that Ranorex Spy includes wildcards (*/*) in the path to an object, which increases the reliability of the selector. If there is a change in the hierarchy of the application, the automated test will still be able to find the UI element.
Building stable locators
The following principles help ensure that your automated tests can find your UI objects reliably.
Avoid coordinate-based recognition
Coordinate-based recognition locates a UI object based on its (X,Y) grid coordinates plus a length value. For this to work, the object must always be at the same spot on the screen. Given that any change to the layout of the UI would break coordinate-based recognition, this approach was fragile even on legacy applications designed for fixed-size screens. It’s even more unstable in today’s environment of varied screen sizes, resolutions and orientations.
Avoid image-based recognition
In image-based recognition, an automated test does a pixel-by-pixel comparison of a stored image to the screen image. If the image of the desired UI element is found, then the coordinate value of its location is returned to the automated test. Using image-based recognition to locate a specific UI element is subject to the same inherent weakness as coordinate-based recognition and should be avoided, if possible. On the other hand, you can certainly do image-based comparison in an automated regression test, because in that case, you are using the image itself as a UI object rather than using it to find another object.
Avoid using dynamic IDs
A dynamic ID is one that changes each time the application or web page is loaded. Dynamic IDs are often associated with dynamic content, such as a web page that displays the current date and time. The ideal approach is to create a permanent, unique ID for each UI element in your application and use that to locate objects. If that’s not possible, use another unique attribute such as the object name (unless that is also dynamic), link, CSS or XPath. Ranorex Studio supports the use of weight rules to filter out an object’s dynamic ID and use another property for object identification, along with conditions to control when the weight rule should apply. To learn more about this approach, read the Ranorex blog article Automated Testing and Dynamic IDs.
Use the shortest path
Keep the path for object recognition as short as possible, balancing the twin goals of fast and stable object recognition. For example, if you are creating an automated test for a web page, use the closest relative object such as the immediate parent or child of the UI element. The exception to this rule is if the parent or child object does not have a unique ID, but the grandparent object does, then use the grandparent object instead for increased stability.
The following video demonstrates object identification using the RanoreXpath. The RanoreXpath is based on the XPath query language for selecting nodes from an XML document, but includes capabilities not available in the XPath WC3 standard.
Additional best practices
The following practices will help make your UI tests more resilient and reduce maintenance.
Use an object repository
Using a repository to manage your UI objects allows you to separate the definition of a UI element from your test automation code. Then, if you must change the selector for a UI element, you only need to make the change once for every test case that references the object. A shareable object repository can also enhance collaboration between testers and developers.
Get your developers involved
As mentioned earlier, having a unique ID for each UI element makes test automation much simpler. In addition, developers can assist the testing effort by creating log files to record application behavior, as well as other indications of the application’s status such as meaningful error messages, status bars and breadcrumbs.
Troubleshooting object recognition
Even when using stable locators, object recognition can sometimes fail. Below are tips to help you resolve issues with object recognition.
Invisible UI elements
Elements such as drop-down menus, pop-up windows and combo boxes may become visible only after a mouse-click, and disappear when the application loses focus. To handle this, make sure your automated test includes the steps that a user would normally perform to bring focus to the desired UI element. It may also be necessary to include a wait time in your automated test, and delay execution until the desired element becomes visible.
Snapshots
If you are an existing Ranorex customer, or are evaluating Ranorex, you can generate snapshots to share with our support team for assistance in identifying UI objects. The following video demonstrates how to check the ability of Ranorex Studio to identify the UI elements in your application