So far we have seen how to launch the apps (HICC) in Appium Inspector. In this article you’ll learn how properly using Locators is key to building your automation scripts. After all, if you’re unable to “find” the UI element, you cannot control it.

What is an Element Locator?

An Element Locator is nothing but an address that identifies a UI Element on a Mobile App (or Website). As there are many UI elements present on a single mobile application screen there can be a chance that the same (generic) address can refer to more than one element. This means that we need to find a unique address for the element. As you will see, sometimes this is easy, and other times you have to do some further exploration to uniquely identify your UI element. The way in which you uniquely identify the element is called a locator strategy. Appium makes many different strategies available.

There are many different locator strategies available and learning which type of strategy to use is part of the learning process of becoming comfortable with Appium. We will go through the below Locator Strategies (in the order of preference) in detail.

1. ID
2. Accessibility ID
3. Name
4. Xpath
5. Class Name

ID

This is the most common and preferred locator strategy for mobile apps automation because it is a unique element identifier and results in finding the element much more quicker.

Android: We can use id or resource-id attributes.

In the above screenshot, we have launched an Appium session for the HICC Android app.

The syntax is as follow: <app-package-name>:id/<id-name>

You can copy the id as is from the Appium Inspector or you can just use the <id-name> part from the syntax.

iOS: label or name attribute of an element is used as the ID.

While in Appium for iOS devices, this type of ID locator is still listed as accessibility id, it can be used as a regular id. We will discuss the difference between accessibility id and resource-id shortly.

In either case, a test script using resource-id or label would look like this:

Accessibility ID

This is also the most preferred strategy after the ID locator in Appium. It is also one of the fastest performing locator strategies.

Android: Accessibility ID for Android is the content-desc property of the element.

iOS: it’s the accessibility-id property.

As we observed earlier, accessibility id is listed for iOS devices for elements with label attributes. But accessibility ids are also listed when an element has ‘content-description’ for Android devices or ‘name’ attribute for iOS devices.

Below are the screenshots for Android and iOS respectively:

In cases like these, we cannot construct a locator with id=<accessibility-id> as the target syntax since these are not regular IDs. We must then use them as XPaths instead of concrete locator types. Just click on the XPath selector to copy it from Appium. We can then paste these into our test scripts.

An example for the ‘hamburger menu’ element would be:

Accessibility ID locators are also the go to locator types, but take lesser precedence because not every element might have a clear content-description or name attribute. Regular IDs are meant to be unique and are used to identify the exact element.

If you find that in your application under test if there is any element that is not dynamic but still does not have the accessibility id set, nor does it have any ID set, then you should ask your development team to add those attributes. This will help you save so much time that you may have to build other locators in Appium like XPath, CSS etc..

Name:

This is one of the common locator strategies in Appium or selenium.

iOS & Android: It’s the name attribute of the element on both platforms. This isn’t used as often as accessibility id and id strategies are mostly used.

Xpath

XPath is short for ‘XML Path’, which just means a string constructed from the root of the page source until the required element. Consider a folder on your PC that also has a ‘path’ like…

C:\Users\user-name\parent-folder\required-folder

In mobile apps, the availability of regular IDs and Accessibility IDs make it easier to write locators, there is a good chance that all elements in the app will not have these attributes. IDs are the preferred way to write locators due to their simplicity, but we can construct specific XPaths that identify the exact element, which content-description or names would not always allow.

This strategy should ONLY be used when there is no Accessibility Id, Id or Name assigned to an UI Element. XPath has performance and stability issues but is very “brittle” changing across platforms and even device manufacturers.

• Now the question is why would you ever use XPath?

It can literally find any UI element in the even if no ID or Name is present, you can still find it with XPath.

If you are using the Appium Inspector for inspection of the App source then Appium will give you the XPath directly without any extra effort.

Let us consider the three inputs – age, income and zip code in the HICC app as examples. You will observe that the Android version of the HICC app has IDs for these three inputs, but iOS does not. Neither does it have other attributes like label or name for us to use them directly and with little modification. In such cases, we must rely on the XPaths of these elements.

Let us write XPaths for the three inputs in the HICC iOS app.

From the above screenshot, we have selected the ‘Age’ input. In the Selected Element section, we have the ‘type’ field which lists the type as ‘XCUIElementTypeTextField’. This is the element type for this input and is also used as the XPath. We can use this directly in the target as:

Let us break this down:

1. We copied the XPath from the ‘type’ field.
2. We added “//” before it because this is not the first element in the app source and must be found somewhere much deeper within. We would add “//” for every XPath that is being constructed from the middle of the app source.
3. We enclosed the XPath within parenthesis and added an index of ‘1’ since the age input field is the first element of this type. The income is ‘2’ and the zip code is ‘3’.
4. Finally, we added “xpath=” so that SaaS understands what kind of a locator it is.

The syntax that we have followed is:

element-name[@attribute-name=“value”]

Where, element-name is the tag-name of the required element, attribute-name is an attribute which is part of the tag-name of the element and value is the string based on which the element will be identified.

Alternatively,

xpath=(element-name[@attribute-name=“value”])[index]

This is used when we have to add indexes to the XPath.

You can learn more about writing XPath locators in different ways in this link.

As you might have already noticed, there is an ‘xpath’ field listed in Selected Elements. We discourage using extremely verbose XPaths for brevity and debugging purposes. But those can be copied and used directly.

While XPaths are very flexible and complex XPaths can be created with data driven capabilities of Worksoft SaaS, it is not recommended as the first approach due to the reasons that it might require heavy modifications. Working with XPaths requires some experience with various kinds of element tags in Android and iOS devices.

Class Name

A class name within an app is just the name of the element tag. This is called ‘type’ for iOS apps, which we used earlier in XPaths. This offers little flexibility and will identify many elements in the app source if used without modifications. Class names can be used when the element tag is either unique or dynamic with observable patterns to recreate them in the automation. There is no special syntax for class name locator and would be used just like an XPath locator. This takes the lowest precedence due to these reasons.

Below are the screenshots for Android and iOS respectively: