Web Application Profile

Each web application is unique in terms of assigning attributes to elements and this complicates the process of generating XPath locators. Some applications assign dynamic IDs to elements, some use ARIA attributes and some do not, some values of class attribute have meaning related to element position and some just used for element styling. There are also cases when an app contains hidden DOM layers which stack on top of each other. So usage of same set of attributes for generating XPath is not efficient and may lead to weak locators that break after application reloading or slight modification. To cope with these problems Rapise introduces Web App Profile. It is a simple JSON file of a defined structure that instructs Rapise how to build XPath for elements in a particular application. From this topic you will learn how to define a profile for your web application.

Purpose of WebAppProfile

WebAppProfile serves as an instruction to Rapise on how to record XPath locators for elements in a given application.

WebAppProfile addresses one of the challenges in web UI test automation: generation of resilient XPath locators during test recording.

Adding WebAppProfile to a Test

To create WebAppProfile.json file in your test navigate to Files tab, right click Scripts folder and choose Create... > WebAppProfile.json.

The default profile looks like this:

        attributes: [
            { name: "id", notEmpty: true, exclude: "\\d" },
            { name: "class", notEmpty: true, exclude: "\\d"},
            { name: "title" },
            { name: "name" },
            { name: "style" },
            { name: "type" },
            { name: "value" },
            { name: "placeholder" },
            { name: "autocomplete" },
            { name: "href" },
            { name: "role" }
        classes: [
            /* { name: "content" } */
        anchors: [
            /* { xpath: "//div[@class='content-wrapper']" } */

WebAppProfile Format


When XPath of an element is being recorded and the element belongs to the sub-tree of an anchor element then XPath of the element will start with XPath of the anchor element.

Let's look at the example. Here we have a table built with DIVs and ARIA roles.

<div id="Customers" role="grid">
    <div role="row">
        <span role="cell" title="Contoso"></span>

If we record just using title attribute and it's value is unique for the page we'll end up with a locator


However if we define an anchor


we'll get the locator as


The locator is now bound to the table. If another element with Contoso title appears somewhere on the page (outside the table) we'll find the correct element.

Here is more complex and real-life example. In Microsoft Dynamics 365 Business Central application when you navigate through the forms they are loaded into the DOM tree inside DIV elements with spa-view class. When you move from one form to another - old forms are not unloaded and continue to stay in the DOM tree. They just have lower z-index then currently active form.

It means that when Rapise searches for an element during test playback it should work with the topmost spa-view.

To achieve this goal we define an anchor in WebAppProfile for the application

//div[contains(concat(' ', @class, ' '), ' spa-view ') and position()=last()]

Here is an example of automatically recorded XPath

//div[contains(concat(' ', @class, ' '), ' spa-view ') and position()=last()]//span[@aria-label='Customers']

The anchor prevents us from finding elements that are not visible to user and ensure that if we find an element it belongs to an active form.

XPath Minimization

Rapise always tries to build the minimal XPath locator possible with a given set of attributes, classes and anchors. Full XPath is not an option.

Let's assume we have a page

        <span title="Account"></span>

and XPath


finds a single node, then it is a good minimal locator for the element.

Compare with full XPath


that may easily become broken with page layout changes.

See Also