On this page, you’ll find out how RanoreXPaths are structured and how RanoreXPath characteristics relate to automated software testing. We’ll first explain the RanoreXPath structure for an isolated UI element, and then for this UI element as part of the UI it is situated in. Finally, we’ll explain what robustness and flexibility are in relation to RanoreXPaths and how to make use of them for test automation purposes.
In this chapter
Basic structure for an isolated UI element
Normally, a full RanoreXPath points to a UI element in the UI it is situated in. However, to explain the basic structure of a RanoreXPath for a single UI element, let’s take a look at what’s required to point to the Exit button in the Ranorex Studio Demo Application in isolation:
Basic structure: The RanoreXPath for an isolated UI element consists of three elements: an axis specifier, a node, and zero or more predicate(s) (all explained below).
For the isolated Exit button, the axis specifier is /, the node is the role
button, and the predicate consists of an attribute-value pair that uniquely identifies the button.
- Ranorex Studio treats UIs as a hierarchical tree.
- Axis specifiers indicate in which direction the RanoreXPath navigates within this tree.
- Examples for axis specifiers are
ancestor. For more information on axes, refer to ⇢ RanoreXPath syntax.
- Node refers to a distinct node (i.e. UI element) in the UI element tree.
- In RanoreXPath, the UI element’s role is the primary property by which it is identified.
- For more detailed identification, roles can be further specified with predicates enclosed in square brackets
- Predicates further specify a node/role. They are optional.
- A predicate normally consists of one or more attribute-value pairs.
- Predicates are enclosed in square brackets.
- Attribute-value syntax is:
@attribute='value', where = is the operator.
- Operators other than
=are available for use (explained ⇢ here).
- Predicates may also contain ⇢ regular expressions.
Structure of a full RanoreXPath
Above we explained the basic structure of the RanoreXPath for an isolated button, i.e. one isolated node in the UI element tree. We ignored the ancestor nodes that represent the UI this button is embedded in (e.g. the Ranorex Studio Demo Application window, the Introduction tab, etc.). Naturally, to identify the button in a real-life scenario, the RanoreXPath needs to navigate through all these ancestor nodes to get to the Exit button.
Chain isolated RanoreXPaths together
To get to the Exit button, we simply chain the RanoreXPaths for the isolated nodes/UI elements leading up to it together. This leaves us with the full RanoreXPath for the Exit button, which consists of three parts, like any other full RanoreXPath:
The root of the current UI element tree. This is the starting point for navigating to the final node/UI element.
Path from root to final node
The nodes between root and final node. Can be zero or more.
Final node/UI element
The UI element you want to identify.
This does not mean that a full RanoreXPath always consists of three nodes. The parts described above can all be contained in one node (e.g. when identifying only the Ranorex Studio Demo Application window), in two nodes (when there are no other nodes between root and final node), or many more than three (when there are several nodes between root and final node).
Let’s take a look at the full RanoreXPath for the Exit button as it’s generated when tracking the button from Ranorex Spy.
Tracked Exit button
The RanoreXPath generated for the button by Ranorex Spy.
The views in Spy provide more details and demonstrate which UI elements the RanoreXPath navigates through/identifies.
The UI element tree browser shows the two UI elements in the RanoreXPath in the UI hierarchy.
- The root element is the program window (=form) of the demo app.
- It is identified by its controlname
- The final node is the Exit button.
- It is identified by its controlname
- There are no intermediate nodes between root and final node.
The path editor shows a more visual representation of the RanoreXPath, with details as to what node corresponds to what part of the RanoreXPath expression.
The full RanoreXPath expression for the Exit button is:
Robustness and flexibility
In UI test automation, robustness means that the test will still work if changes are made to the UI, e.g. moving a button from one place to another or changing its label. In Ranorex Studio, this is accomplished through the RanoreXPath.
An ideal RanoreXPath is as detailed as necessary (= more robust) and as flexible (= faster UI element identification and therefore execution speed) as possible.
- The level of detail vs. flexibility impacts robustness and execution speed.
- A very detailed RanoreXPath leads to less robust declarations but may speed up test execution.
- A very flexible RanoreXPath is more robust against UI changes, but may also slow down test execution.
Increase flexibility with wildcards
When you want to increase the flexibility, and therefore the robustness, of a RanoreXPath, you can do so by adding wildcards to it. When Ranorex Studio generates RanoreXPaths automatically, it will also add wildcards if necessary to balance the RanoreXPath between flexibility and UI element identification speed.
Let’s take a look at an example to see how Ranorex Studio automatically inserts wildcards. We’ll track the Female radio button in the Test database tab of the Ranorex Studio Demo Application to have Ranorex Studio automatically generate a RanoreXPath:
In Ranorex Spy, click Track.
In the Ranorex Studio Demo Application, click the Female radio button in the Test database tab.
Ranorex Studio automatically generates a RanoreXPath for the UI element.
- The generated RanoreXPath expression. Compare it to what’s displayed in the element tree browser and the path editor.
Element tree browser view
- Displays the hierarchical structure of the UI the radio button is embedded in.
- It contains five different UI elements.
- Displays a visual representation of the nodes in the RanoreXPath expression.
- There are seven nodes in total, including the root and final node.
Let’s take a closer look at the automatically generated RanoreXPath expression as it’s displayed in the path editor:
This node represents the program window of the application under test (i.e. the Ranorex Studio Demo Application) and is a fixed part of the RanoreXPath expression.
To make the RanoreXPath expression more flexible, Ranorex Studio has inserted two wildcards
/? (= any optional) between the root and the next fixed part. This means that between these two parts, either zero, one, or two nodes can be present and Ranorex Studio will still be able to find the final UI element.
Ranorex Studio has designated this UI element to be a fixed node that’s necessary for identifying the radio button correctly.
Ranorex Studio has inserted two more
/? wildcards to further increase the flexibility of the RanoreXPath expression.
The Female radio button is the final fixed part of the RanoreXPath expression; the actual UI element we want to identify.
- Wildcards increase the flexibility of a RanoreXPath. They allow Ranorex Studio to identify UI elements even if the UI structure they are embedded in changes. Wildcards can therefore increase robustness when applied correctly.
- In the example above, Ranorex Studio generated a RanoreXPath with three fixed nodes. These provide the required detail for accurately identifying the correct UI element (the Female radio button).
- Ranorex Studio also included four
/?wildcards. These provide flexibility and ensure that changes to the UI structure between the fixed nodes won’t break correct identification of the Female radio button.
- There are three different wildcard operators in total, explained below.
There are three different wildcard operators in Ranorex Studio:
||any||Any UI element in exactly one (1) tree level|
||any optional||Any UI element in exactly zero (0) or one (1) tree level|
||any descendants||Any UI element in any number of tree levels|