Locators

This article focuses on locators, what they are, what the options are, and when/why you should use them.

No matter the technology, the term locator is basically a pointer to identify the input fields, buttons, text on screen, etc., of the website/application you are automating. In our terminology, the term selector refers to the raw string that defines the locator, for example, a raw xpath -string we consider to be the selector of a Browser Locator.

There is a lot to unpack here, so the sub-pages and links provided here will take you in as deep as you want to go, but rather than looking at everything at once, it is better first to know what option would work for you.

Different locator types

Different locators work in different cases, so good to know the options:
👉 Browser Locators: When automating websites that do not offer an API
👉 Windows Locators: When automating Windows applications based on UI's
👉 Image Locators: When the website/application just does not provide any way of getting the above locators.
👉 Java Locators: When automatinc Java applications based on UI's

❗ Before jumping into using locators, do not forget to check that there is no direct API or data-level access to perform the automation.
Automating against something that is made for machines is always an order of magnitude faster than dealing with user interfaces.

Locators in Robocorp Tools and Robot Framework

🚀 You can manage and create Locators in VS Code

If you create the locators using Robocorp tooling, the locators get saved in your robot as a simple configuration file and images. You can then use the stored locator in your robot code via aliases, which means that if you need to update the locator, your robot code can stay untouched. By using reasonable naming in your stored locators, you also make your robot a lot more readable.

As seen above, you can still write the raw selector syntax in your robot, and there are cases where it is better.

Another good thing to note is that sometimes you do not even need to make locators. So the example above, which accepts the cookie policy on google.com, can also simply be done like this:

...but do note that the last option will fail if the element is not typed to be a Button or if there are multiple buttons with the same text on the page. So a unique locator is always the most robust solution.

Browser Locators

When automating websites on their UI's, Browser locators should be the first thing you look at.

Browser locators are based on the website's source code and enable you to find the elements on the website based on various identifiers. Finding a solid logic for the locator is the key to a robust and reliable robot. A good locator can cope with significant changes to the website UI. Components can change place, colors, content, etc., but if the locator points to, for example, an element id that is always unique, your robot will keep working.

You will run into terminology like: xpath, css, id, name, class, ...

As Browser Locators work inside the web browsers, they can be made and run on Windows, Linux, and macOS.

👉 Browser Locators delves deeper.

Windows Locators

Windows Locators target the element structure of an application. The majority of Windows applications have and expose the structure so that things like element fields like automationid or name can be accessed and targeted. Similar principles apply here as with the Browser Locators; selecting the right selectors of fields and values are the key to a robust locator.

It is good to point out that there is still a good chunk of really old Windows applications out there. Old technology stacks only sometimes expose a reasonable structure, and even some newer applications can be implemented in a way where finding solid element structures and selectors can be really hard.

If our tools fail to pick the locator from your target application, there is always the Accessibility Insights for Windows from Microsoft that enables you to see the raw view.

Windows locators are, of course, limited to only the Windows platform.

👉 Windows Locators delves deeper.

Image Locators

As image locators are functionally looking for image comparisons against the desktop, they can work with application and browser automations, however...

Image Locators should be the last line of defense, so before getting here, you could/should have already checked the following:

• The target has not been updated so that it has an API, data-level access, or newer website/application.
• The other types of locators cannot be made because the target does not provide reliable locators.
• The automation cannot be done using hot-keys and Send Keys -keywords

The reason for the list above is that relying on the target UI to stay the same shape, size, color, layout, etc., normally makes it hard to get the Image Locators into a robust state.

Image Locators are supported for Windows and macOS, in VS Code

👉 Image Locators delves deeper.

Java Locators

Java Locators target the element structure of an Java application. The most common element fields in Java applications role and name can be accessed and targeted. Similar principles apply here as with the Browser Locators; selecting the right selectors of fields and values are the key to a robust locator.

We have built Assistant for working with Java application's element structure and locators. The Assistant provides default copy pasteable locators for each element and also allows testing locators against selected application.

If our tools fail to pick the locator from your target application, there is always the Access Bridge Explorer from Google that enables you to see the raw view.

Java locators are limited only the Windows platform.

👉 Java Locators delves deeper.