Overview

When testing mobile applications in Rapise, the underlying engine (Appium) represents the mobile user interface as an XML document. This allows you to use standard XPath 1.0 syntax to locate elements.

However, unlike web testing where XPath targets HTML tags (like <div> or <button>), mobile XPath targets the native UI components specific to the Android or iOS platform.

To write effective XPaths for mobile, you need to know the correct node names (the element types) and attributes (the element properties) used by each operating system.

Android XPath Syntax

On Android, the XML node names correspond to the Android UI class names, and the attributes correspond to the element properties available in the Android UI tree.

Common Android Node Names (Tags):

  • android.widget.TextView (Text labels)

  • android.widget.Button (Buttons)

  • android.widget.EditText (Input fields)

  • android.view.View (Generic views)

Common Android Attributes:

  • @text: The visible text of the element.

  • @content-desc: The accessibility description of the element.

  • @resource-id: The unique ID assigned by the developer (often written as package.name:id/element_id).

  • @class: The class name of the element.

Android XPath Examples:

  • Find a button by its exact text:
    //android.widget.Button[@text='Login']

  • Find an element by its accessibility description:
    //*[@content-desc='Submit']

  • Find an input field by its resource ID:
    //android.widget.EditText[@resource-id='com.example.app:id/username']

iOS XPath Syntax

On iOS (via XCUITest), the XML node names correspond to Apple's XCUI element types, and the attributes map to the accessibility properties of the iOS elements.

Common iOS Node Names (Tags):

  • XCUIElementTypeButton (Buttons)

  • XCUIElementTypeStaticText (Text labels)

  • XCUIElementTypeTextField (Input fields)

  • XCUIElementTypeCell (Table or list items)

Common iOS Attributes:

  • @name: The accessibility identifier or the name of the element.

  • @label: The visible label text of the element.

  • @value: The current value of an element (e.g., text in a text field).

iOS XPath Examples:

  • Find a button by its name:
    //XCUIElementTypeButton[@name='Login']

  • Find static text by its label:
    //XCUIElementTypeStaticText[@label='Welcome back']

  • Find an element containing a specific value:
    //*[@value='Enter your email']

Useful XPath 1.0 Functions (Both Platforms)

Because standard XPath 1.0 is supported, you can use built-in XPath functions to handle dynamic properties or complex hierarchies on both Android and iOS:

  • Partial Match (contains)
    Locate an element where the text or name partially matches a string.

    • Android: //android.widget.TextView[contains(@text, 'Welcome')]

    • iOS: //XCUIElementTypeButton[contains(@name, 'Submit')]

  • Starts With (starts-with)
    Locate an element whose attribute begins with a specific string.

    • Android: //*[@content-desc[starts-with(., 'menu_')]]

  • Multiple Conditions (and / or)
    Combine multiple attributes for a more precise locator.

    • iOS: //XCUIElementTypeButton[@name='Confirm' and @visible='true']

  • Hierarchical Navigation (parent, following-sibling)
    Navigate the UI tree relative to another element.

    • Example: //*[@text='Username']/following-sibling::android.widget.EditText

Best Practices & Tips for Rapise Users

  1. Use the Mobile Spy: You do not need to guess the exact node names or attributes. Use the Rapise Mobile Spy to inspect your application. Clicking on an element in the Spy will automatically reveal its properties and help you generate the correct XPath.

  2. Wildcards vs. Explicit Tags: While //*[@text='Login'] is convenient, replacing the wildcard * with the exact class name (e.g., //android.widget.Button[@text='Login']) is recommended to make your tests faster and more reliable.

  3. Prefer Accessibility IDs: While XPath is incredibly powerful for complex UI queries (like finding an element based on its sibling), it can be slower to evaluate on complex mobile screens. Whenever a unique @content-desc (Android) or @name (iOS) is available, prioritize using those as your primary locators.