Xpath keeps changing

577 views
Skip to first unread message

PD

unread,
Jul 14, 2014, 1:49:46 PM7/14/14
to appium-...@googlegroups.com
I have been using Appium for about a month now and had the following observations:

1) Xpath for the same elements - for the same Native app version - are different when the iOS simulator version changes. e.g. iOS6,iOS7 have different xpath for the same elements. 

2) Then the code written for iOS7.1 simulator does not identify xpaths in iOS7.1.2 real device.

Why is this happening? Do we have to maintain different sets of code for different versions of iOS?
Appium version has been 1.1.0 throughout.

Thanks in advance!

bootstrap online

unread,
Jul 14, 2014, 1:55:42 PM7/14/14
to PD, appium-...@googlegroups.com
Don't use xpath.
> --
> http://appium.io
> ---
> You received this message because you are subscribed to the Google Groups
> "Appium-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to appium-discus...@googlegroups.com.
> Visit this group at http://groups.google.com/group/appium-discuss.
> For more options, visit https://groups.google.com/d/optout.

PD

unread,
Jul 14, 2014, 1:58:12 PM7/14/14
to appium-...@googlegroups.com, pranj...@gmail.com
Thanks for the quick reply.
Our product lacks unique IDs for now, hence was trying to see how xpath works.

Is the change happening due to different versions of iOS? I need to understand what is causing paths to change every time.

Thanks.

bootstrap online

unread,
Jul 14, 2014, 2:49:57 PM7/14/14
to PD, appium-...@googlegroups.com
XPath has had 219 issues. It's not a viable option. The implementation
is broken in strange ways.
https://github.com/appium/appium/search?q=xpath&ref=cmdform&type=Issues

You'll have better luck using predicate searches on iOS to find
elements without unique ids. On Android this is done with instance
selectors, the same concept can apply to iOS. Even if XPath worked,
major iOS releases often require maintaing different xpaths.

PD

unread,
Jul 14, 2014, 2:54:47 PM7/14/14
to appium-...@googlegroups.com, pranj...@gmail.com
Thank you so much!

Jonathan Lipps

unread,
Jul 14, 2014, 6:56:37 PM7/14/14
to PD, appium-...@googlegroups.com
And to answer your specific question, yes iOS6 and iOS7 will sometimes have slightly different hierarchies for the same app.
signature.asc

PD

unread,
Jul 14, 2014, 9:01:24 PM7/14/14
to appium-...@googlegroups.com, pranj...@gmail.com
Thanks!

To all those people who have successfully managed mobile tests - do you keep updating the code for newer versions of iOS and fore newer devices? how often ?

bootstrap online

unread,
Jul 14, 2014, 11:33:13 PM7/14/14
to PD, appium-...@googlegroups.com
I use accessibility labels so it's consistent across iOS revisions.

Vic Wong

unread,
Jul 15, 2014, 1:46:01 AM7/15/14
to appium-...@googlegroups.com, pranj...@gmail.com
Obviously ids are the least brittle, but I still personally use a lot of xpath, and I don't think we should be dismissing it so quickly. IDs simply are not always an option.

We use name/label/value matches whenever possible. Raw xpath with no labels/values is going to be unreliable. Even if your element doesn't have a proper id, is surely must have a value or label on it that can be extracted?

If not, usually we have found that you can generalize an xpath to work on both platforms. Often there are only subtle index differences like: 
iOS 6 //window[1]/cell[2]/button
iOS 7 //window[2]/cell[3]/button

Depending on how the rest of your element tree looks, you might be able to get away with using this for both: //window/cell/button

Or surely in a example like this, the button would contain a common string label. You could try something like:
//button[@value='match']
//button[contains(@value,''substring')]

If you need cross-version support simultaneously, you can put some conditional logic in your element's definitions. Example, if (version > 7) { button = By.xpath( //window[1]/cell[2]/button) } else { button = By.xpath(//window[2]/cell[3]/button)

In my experience avoiding numerical xpath indexes and pairing with label/value/name matches leads to minimal maintenance on our part. Now when a developer decides to change things around, that's another thing... and probably beyond our control :)

-v

bootstrap online

unread,
Jul 15, 2014, 9:08:37 AM7/15/14
to Vic Wong, appium-...@googlegroups.com, Pranjal Deo
Everything you pointed out can be done better with predicate searches.
If you're fine with the existing xpath bugs such as returning random
elements, keep using it.

PD

unread,
Jul 15, 2014, 12:56:42 PM7/15/14
to appium-...@googlegroups.com, vic...@gmail.com, pranj...@gmail.com
Thanks!

Could you please give an example of 'accessibility labels' and how you use it in your code?
Thanks.

bootstrap online

unread,
Jul 15, 2014, 12:59:07 PM7/15/14
to PD, appium-...@googlegroups.com, Vic Wong

Wayne Ma

unread,
Jul 15, 2014, 1:46:52 PM7/15/14
to appium-...@googlegroups.com, vic...@gmail.com, pranj...@gmail.com
Could you please give some example on predicate search (using ruby_lib preferably)?


On Tuesday, July 15, 2014 6:08:37 AM UTC-7, bootstraponline wrote:

bootstrap online

unread,
Jul 15, 2014, 1:52:01 PM7/15/14
to Wayne Ma, appium-...@googlegroups.com, Vic Wong, Pranjal Deo
There's documentation available including a ruby_lib example.
http://appium.io/slate/en/master/?ruby#toc_122

On the next appium server release, ruby_lib will be updated to use
predicates for the helper methods automatically.
Reply all
Reply to author
Forward
0 new messages