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.
❗ 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 and Automation Studio
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.
# Which is more readable? Click Element alias:google-accept-all # ..or.. Click Element //button/div
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.
google.com, can also simply be done like this:
Click Button Accept all
...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.
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:
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 target the element structure of an application. The majority of Windows applications have and expose the structure so that things like element fields like
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.
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.