When working on UI test automation for a web application a test engineer has to deal with XPATH expressions. They are used to locate UI elements during test execution. It is very important to use such XPATH expressions that do not break when developers update the application. Good XPATH expressions which still find required elements after UI modification can be referred to as resilient or elastic.
In this article we'll consider several examples of elastic XPATH expressions.
By default straight forward XPath to SVG primitives will not work. So XPath ending like .../svg[2]/path will fail. Here is a workaround.
When Rapise starts execution of a test, it sets working directory. If a test refers to a file using a relative path then the absolute path is calculated using the working directory.
In some cases it may be convenient to construct Rapise Objects dynamically rather than capture in advance with record/learn. In Web tests you can do it via Navigator.Find and Navigator.SeSFind.
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 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 article you will learn how to define a profile for your web application.
We had a customer with a problem related to having <div> elements with complex display styles applied inside an HTML anchor tag <a>. The anchor tag was reporting back as having zero size (0px) in IE, so when Rapise tried to locate it to click on it, the browser was not able to find it.
When recording or playing back a test script on a new PC you may get an error message that Rapise cannot find the path to "AllLibraries.json".This article provides instructions on how to fix the issue.
When testing complex data-driven web applications using Rapise, it is helpful to understand the different ways that Rapise can automatically learn the objects. Rapise can learn an object using either XPATH or CSS. In the case of XPATH there are several strategies that Rapise can use to make the testing more robust. This article describes these strategies and provides some suggestions about which one is the best to use for different scenarios.
Sometimes you want to dynamically change the XPATH or CSS used in a specific object from within the test script itself. This article explains the process for doing this.
When testing web applications you will often need to use XPath to query the browser DOM for elements based on the scenario under test. This guide explains how you can use XPath queries with Rapise to make your browser testing more flexible and adaptive to changes on the screen.
Often you want to be able to query for the child elements on a web page that are dynamically created and therefore not good candidates for LEARNing individually. This article explains how you can use the dynamic XPATH methods of Rapise to accomplish this task.
Are you writing XPath to find an element using its inner text but it does not work? Most likely the text contains non-breaking spaces.
This situation is described in detail in our UI Test Automation Playground.
Imaging you have a table with dynamic data on the page. It is not possible to learn every cell. But it is possible to parameterize the locator of a cell and access cells you need during test playback.