3

I am new to mobile automation and Appium and unable to find a way to get xpath or locate an element, getting following node details in uiautomatorviewer:

index:0
text:
resourceid:
class: android.view.View
package: com.divami.balfour

enter image description here

Node tree structure and Node details image for element text field

  • can you get to another another neighboring node and use relative xpath to get to the node you need? – StanM Jun 5 '15 at 19:23
1

I can not comment yet, so I will post it as an answer, but it is basically a clarification for Dmitry's answer.

.//View[@content-desc='PASSWORD']/../EditText

From tree view we can notice that the element we want to access has no unique identifier, but the View which is on the same level of hierarchy has content-desc set to PASSWORD. So, first we can look up for this element that can be somewhat uniquely identified by its description

.//View[@content-desc='PASSWORD']

The EditText we want to find is a child of the same parent, so we simple has to go one level up .. and then get the element by its tag EditText. In this way searching for element by tag EditText will be limited to children of (2) View.

This approach should be better then //EditText[2] as it does not relay on order of elements in UI.

But Butch's answer is even more preferably, as it is always a better idea to supply unique identifiers for elements that are important for testing, as it will make test easier to maintain (no need to change locators on minor UI changes).

| improve this answer | |
0

Try this:

.//View[@content-desc='PASSWORD']/../EditText
| improve this answer | |
  • 2
    Could you explain how to came up with this xpath? Your answer needs more context to help people understand whats happening here with the xpath. – IAmMilinPatel Jul 10 '15 at 17:24
0

So this is somewhat of an answer, but may not be one that works for you depending on your circumstances. X-Path seems like a good idea when you need to find something, but I have found in my situations (automating a web application) they are very brittle and when something on the page changes, the X-Path is normally broken. My recommendation is going back to a dev on the project and having them add some sort of unique identifier like an ID. I am not too familiar with mobile development but I'm sure there is some kind of unique identifier that could be put on that field.

| improve this answer | |
0

A literal approach would be:

//EditText[2]

This simply goes to the 2nd Edit text field on the page. For something simple like a sign-in page this would be ok since you aren't likely to add/remove text fields. However, as Butch notes, this kind of literal path can be brittle on pages with multiple elements that are frequently changing.

Another option is to design a 'smarter' xpath locator much like Dmitry stated.

His looks for the specific View element (PASSWORD) regardless of its position and then navigates to back up to the parent node VIEW (using '../') then back down to the EditText element

| improve this answer | |
0
//*[text()="PASSWORD"]/following-sibling::android.widget.EditText

or

//*[text()="PASSWORD"]/following-sibling::android.widget.EditText[@index='1']
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.