Test Automation Best Practice #4: Use Reliable Locators

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.

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.

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.

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.

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.

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.

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.

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