How to Pick the Right Locator Strategy

Reader Venkata recently asked us to compare and contrast the different selector strategies available. If you have the luxury to choose, which is the best pick?

We've written about element selectors quite a bit already. For those new to the subject, we have a good overview of what selector strategies are and how to use them. I'm going to omit mention of Web and Hybrid tests here and focus just on the selector strategies provided by Appium for native iOS and Android testing using the UiAutomator2 and XCUITest drivers.

Without further ado, here's our prioritized list of locator strategies:

1. accessibility id
2. id
3. xpath
4. class name
5. Locators interpreted by the underlying automation frameworks, such as: -android uiautomator, -ios predicate string, -ios class chain
6. -image

Check out: Automating Physical Buttons on iOS Devices

Now don't go running to your fellow testers using this list to settle an argument. Every app is different, and assembling this list is like making a list of the "best" pieces in chess: they all have their uses.

1. accessibility id

That this is the top choice should surprise nobody. If you have the option of using accessibility IDs, use them. Normally an app developer needs to add these specifically to UI elements in the code. The major benefit of accessibility IDs over just the id locator strategy is that while app developers add these IDs for testing, users with handicaps or accessibility issues benefit. People who use screen readers or other devices, and algorithms which inspect UIs, can better navigate your app!

Also check: How to Pick the Right Locator Strategy

On Android, this locator strategy uses the accessibility contentDescription property.

On iOS, this locator strategy uses the accessibility identifier. Here's something surprising: in the XCUITest driver, the accessibility id, id, and name locator strategies are all identical. They are implemented the same way. Go ahead and try switching your locator strategies, you will get the same results. This may change in the future, but for now you can find an element using the name or text in it because iOS has many ways in which it sets a default accessibility identifier if one is not provided by the developer.

Read: A Complete Guide to XCTest

2. id

Element IDs need to be added by a developer, but they allow us to pinpoint the exact element in the app we care about, even if the UI changes appearance. The drawback is you need to be able to talk to your developers. Many testing teams do not have this luxury.

This locator strategy is pretty similar to accessibility id except that you don't get the added benefit of accessibility.

As noted above, on iOS, this is actually identical to accessibility id.

On Android, the id locator strategy is implemented using Resource IDs. These are usually added to UI elements manually by app developers, though are not required, so many app developers will omit them if they don't think they're important.

Also read: Capturing App Launch Metrics on Android

3. xpath

Now this is contentious. XPath is the most expressive and commonly accepted locator strategy, but Appium developers have long warned of its drawbacks. This earlier edition goes to some depth in explaining why XPath should be avoided.

Despite Appium developers warning against XPath's low performance for years, it still seems to be the most popularly used locator strategy. This is probably because there are many selections that can't easily be made any other way. For example, there's no way to select the parent of an element using the simple id selectors. The benefit of being able to express more complicated queries must outweigh the cost to performance for all but the testers whose apps have such large XML element hierarchies that XPath is completely unusable. Those who need performance and flexibility can use the native locator strategies in the next section (and I'll explain why I put them at #4 instead of #3).

XPath selectors can be very brittle, but they can be responsibly wielded to great effect if you follow the guidelines of this earlier edition. Being intentional and carefully picking selectors rather than taking whatever an inspector provides can mitigate the brittleness.

I think part of the popularity of XPath stems from its use with Selenium and web development, as well as it being the default of many tutorials and inspection tools. When working on Appium I always expected our XPath handling to break more often, but I remember few bugs, probably the benefit open-source XPath libraries built for more generalized use.

The Android OS provides a useful dumpWindowHierarchy which gives us an XML document of all the elements on the screen. From there we apply the XPath query and find elements.

iOS does not supply a method of getting the entire hierarchy. Appium's implementation starts at the root application element and recurses through each element's children and populates and XML document which we can then apply the XPath query to.

Check out: Appium for Mobile Testing Infrastructure Setup

I still think XPath is unintuitive, especially for those new to programming, but at least it's a well-accepted industry standard.

4. -android uiautomator, -ios predicate string or -ios class chain

I call these the "native" locator strategies because they are provided by Appium as a means of creating selectors in the native automation frameworks supported by the device. These locator strategies have many fans, who love the fine-grained expression and great performance (equally or just slightly less performant than accessibility id or id).

These locator strategies are crucial for those who have UIs which escape the grasp of the other locator strategies or have an element tree which is too large to allow the use of XPath. In my view, they have several drawbacks.

These native locator strategies require a more detailed understanding of the underlying automation frameworks. Uiautomator and XCUITest can be hard to use, especially for those less familiar with Android and iOS specifics. These locator strategies are not cross platform and knowing the ins-and-outs of both iOS and Android is challenging.

Read: Challenges in Performance Testing on Mobile Devices

In addition, the selectors passed to these native locator strategies are not directly evaluated by the mobile OS. Java, Kotlin, Objective C and Swift all lack an eval function which would allow interpreting a string of text as code. When you send an android uiautomator selector to Appium, the text passes through a very simplistic parser and uses Reflection to reconstruct the objects referenced in the text. Because of this, small mistakes in syntax can throw off the entire selector and only the most common methods are supported. This system is unreliable and often encounters difficult bugs.

If Android or iOS change the testing classes in new updates, your selectors might need to be updated. Using XPath, Appium will keep track of the OS updates and your selectors should keep working.

A personal quibble I have with these locator strategies is that you are essentially writing a different programming language (such as Java) inside of a string in your test code. Your text editor will not offer syntax highlighting or semantic analysis inside of these queries which makes them harder to maintain.

On the other hand, sometimes there's just no other way, and for those who are proficient in these methods XPath can seem clumsy in comparison.

Check: Writing XPath Queries That Work

5. -image

This locator strategy is pretty nifty. Supported on all platforms and drivers, you can pass an image file to Appium, and it will try to locate the matching elements on the screen. We already went over this in edition.

This supports fuzzy matching, and certainly has its applications, but you should only use it when the other locator strategies aren't working. It may not always behave deterministically, which mean it can be a source of test flakiness. Also, unless you have a special code editor, they may be a little more difficult to work with and maintain. Of course, visual UI changes will always break -image selectors, whereas the other selectors only break when the element hierarchy changes.

That's it! Feel free to drop us a line if you feel passionately about one of these strategies!