Latest Updates. News. Insights. Ideas.

xpath Archives - Sahi Pro

Five Questions Series: Sahi’s Relational APIs

Posted by | features, web automation, xpath | One Comment

In the fourth post on the Five Questions Series, we have Sahi Relational APIs today.
Previous posts in this series: Sahi Controller, Sahi Logs and Sahi Excel Framework.

What is Sahi Relational API
Some times, elements are not uniquely identifiable by themselves. Identifying them in relation to either some element near them or by the element in which they are contained helps. Sahi Relational APIs help you solve that problem. The Relational APIs can be used even on applications with dynamic ids to easily locate one element with respect to another.

Please list the different APIs (markers) under DOM and Positional Relational APIs
There are 2 kinds of relation APIs: DOM Relation APIs and Positional Relation APIs. DOM relation markers like _near, _in specify that the element should be searched near or within another element. Position relations like under, rightOf, leftOf etc. relate one element to another via their position. The list is as follows:
DOM Relation APIs:
_near, _in, _startLookInside, _stopLookInside
Positional Relation APIs:
_rightOf, _leftOf, _leftOrRightOf, _under, _above, _aboveOrUnder
Parent APIs:
_parentNode, _parentCell, _parentRow, _parentTable

How to identify elements using relational APIs?
Identify the main element or the element which is easily identifiable. Then, anchor it and identify the (hard to identify) element in relation to the main element.
Let us take an example to highlight this. In the sample application, we have three books Core Java, Ruby for Rails and Python Cookbook. We also have a text field against each of them.

Relational APIs: Sample Application

Relational APIs: Sample Application

Suppose, we want to identify the text field against the Ruby for Rails. Notice the accessor of the element when no relational API is used. It reads _textbox(“q[1]”).

Relational APIs: Element Accessor without Relational API

Relational APIs: Element Accessor without Relational API

First, identify the main element. In this case, it is the label?-?Ruby for Rails.

Relational APIs: Identify Ruby for Rails

Relational APIs: Identify Ruby for Rails

Anchor the main element by clicking on the Anchor icon.

Relational APIs: Anchor the main element

Relational APIs: Anchor the main element

Identify the secondary element now. Observe the accessor field.

Relational APIs: Identify the second element in relation to the first element

Relational APIs: Identify the second element in relation to the first element

It reads: _textbox(“q”, _near(_cell(“Ruby for Rails”))).

What is the advantage of using _rightOf/_leftOf compared to _near
Using _near where the element to be found may or may not exist can give you unexpected results. For example, in the table below

Relational APIs: Sample Table with missing elements

Relational APIs: Sample Table with missing elements

Let us say we are looking to check if a delete link exists against all users.

_assertExists(_link(“delete”, _near(_cell(“User Two”)))) may be expected to fail, but it passes.
_link(“delete”, _near(_cell(“User Two”))) actually points to the above highlighted link.

This is because, _near is a DOM relation API and finds an element within 7 ancestors (parent nodes) of the given anchor. In our case this link was found within 2 ancestors of the cell in the next row.

The correct way of asserting this would be
_assertExists(_link(“delete”, _rightOf(_cell(“User Two”)))).
_rightOf forces location only along the same line.

Does Sahi Flex Library (SFL) support the Relational APIs?
Sahi Flex Library (SFL) supports near, inside, leftOf, rightOf and under APIs. The usage of these APIs is a little different from the Sahi relation APIs.
The relation APIs are called as member functions.
_f(“mxC”).datagriditemrenderer(“/”).rightOf(_f(“mxComponents”).datagriditemrenderer(“Mary Jones”))

They can be chained to use multiple relations.

Any other questions in your mind?
Feel free to comment or ask your question(s) and we will get back to you.

Stable accessors/locators using UI Relations

Posted by | Sahi, stable tests, ui relations, web automation, web testing, xpath | No Comments

Identification of elements in a web interface is one of the toughest challenges of software UI automation. First came accessing by location (x,y coordinates), which quickly faded away due to window resolutions, rendering differences etc. Then came the concept of identification using code structure. XPath became hugely popular;

Reasons being

  1. Automation was only attempted by established developers and they understood XPaths
  2. 5 years back web applications were simple enough to easily look at the DOM and identify XPaths.
  3. Some (silly!) tools adopted and hugely promoted XPaths for want of innovation on that front.

But XPaths quickly became notorious for being unmaintainable and difficult to understand. If test automation was to spread to non-programmer testers, this would be a huge barrier. Tools then tried to move on to css-selectors, which is still complex for the target test automation teams.

So what could be a possible solution? The answer is in the User Interface.

What is often forgotten in the software industry, is that applications are built to satisfy business needs. So whatever the id, XPath or css-selector is, a textbox meant for “loan amount” will always be near some label saying “Loan Amount”. An expand or collapse icon in a tree gets its meaning from the attached “User name” label for that node. These business requirements do not change as often as code or underlying HTML structure. An HTML table may get converted to an ext-js grid with scrollbars, but the cost will still be associated (and aligned) with a product and listed under the heading “Cost”. Items related to each other would be shown inside a box with an appropriate heading.

How can we use this information to identify elements? Use UI relations for identification. Sahi, which has been a pioneer in web-automation innovation, handles it as below:

A textbox meant for “loan amount” becomes

_textbox(0, _near(_label("Loan Amount")))


browser.textbox(0).near(browser.label("Loan Amount"))

The cost becomes
_cell(0, _near(_div("My product one")), _under(_div("Cost")))
The expand collapse icon becomes
_image("/tree-node-icon/", _near(_span("Expand me")))

  1. These accessors clearly communicate what the intention of the accessor is, in a straight forward way (within the constraints of programming language constructs).
  2. These also take away the complexity in identifying and stabilizing XPaths, or understanding complex css-selectors, or writing custom javascript loops to accomplish the same thing.
  3. They are quite stable. _near allows for more elements to come between two related elements, _under is spatially aligned. So you can move different elements around on the UI and still have your scripts working properly.

UI Relations are guaranteed to exist in any business application, irrespective of whether you have ids or not.

One argument that comes up is, what if there are two similar elements which satisfy the same condition. While it is still possible to index the similar accessors and uniquely identify them, it seldom happens in a real world application. If you have two textboxes near “Loan amount”, it is going to confuse your end user. User-interfaces do not generally have such anomalies. That said, an added index to the accessor handles that scenario too, if it arises.

There is one other simplification that Sahi does in its accessor APIs. It does not explicitly state what the identifying property is. For example what could have been
is simply given as
_textbox("username") in Sahi.

Why? Because there are very few cases where one textbox has name=”username” and another has id=”username”. Such naming would obviously confuse the web developer forcing him to not do something like this.

Combined with UI relations, Sahi also takes care of automatically waiting for AJAX requests and page loads. This makes for robust scripts which hardly have unexpected failures. Other features like parallel playback of suites, automatic report generation, ant integration etc. make Sahi one of the most advanced web testing tools in the industry.

If you have not tried it yet, download from now. You can also use Sahi from inside ThoughtWorks Studios Twist or PushToTest’s TestMaker 6.

Use fully-loaded Sahi Pro FREE for a month. Download Now Request a Demo