I’ve been using Appium for a few weeks now to automate an iPad application, via the Mac Appium app and the Robot Framework Appium Library. I’m having a lot of trouble learning to write any element locators more complex than simple accessibilityLabel references like “id=butnTools” and fragile xpath locators like “xpath=//UIAApplication[1]/UIAWindow[1]/UIAPopover[1]/UIANavigationBar[1]”. There are hints in this forum and other on-line help places about more sophisticated xpath statements like:
UIATableView[label() = 'DLG CAL - Find Roots of a Polynomial']
But that doesn’t work in the Appium Inspector and I can’t figure out any such combination that does work.
One link here pointed to this page, but its very old and totally obscure to me.
Here’s what my app looks like in the Appium Inspector:
“Spinner” elements in dialogs like this one, with buttons labelled ‘+’ and ‘-’, may exist multiple times. So I can’t just tap on an element “id=+” since there may be more than one such element. What I want to do is tap on “the element with id=+ that is the sibling of element with id=dfldTextEntry1”. That would be a completely unique specifier, if I could just figure out how to express it in xpath, or ios format of a locator.
ANY help, including pointers to good quality documentation and tutorials on Appium locator syntax, would be greatly appreciated!
The best thing we ever did in our testing framework was to represent each screen as a different object. Once you do that, then if you know you are on a certain screen (either by looking for unique objects or using accessibility elements) then it’s easy to identify a repeating button like ‘open’, ‘close’, ‘+’, or whatever. For this screen I might identify it by the string, “Find roots of a Polynomial”, and name it polynomial_root_screen (I’m using Ruby). Now I can get element named, ‘+’ of polynomial_root_screen very easily (navigate to that screen, verify we are on that screen, and then click it, or whatever). In fact, I can define a parent for each screen that contains common elements and just maintain them in one file.
This “object per screen” approach is not very practical in my situation. My application-aware test library, written in Python, sits above the Robot Framework AppiumLibrary. This library is meant to be used directly by Robot Framework, so it doesn’t return any Appium objects. Besides, if I took your suggestion and located “Find roots of a Polynomial”, and name it polynomial_root_screen, there is a potential for that screen to have more than one “Spinner” on it with a button that has id=+. That’s the general problem I’m trying to solve here by learning how to write element locators that can express parent-child-sibling relationships between elements.
