Working with the Web Editor – Part 1

Watch this video to get introduced to the Web Editor in LEAPWORK.

In this video:

  • When to use the Web Editor
  • What is a locator strategy
  • Search conditions in strategies
  • Capturing hidden elements

Go to next video.

Overview

Watch this video to get introduced to the Web Editor in LEAPWORK.

In this video:

  • When to use the Web Editor
  • What is a locator strategy
  • Search conditions in strategies
  • Capturing hidden elements

Go to next video.

Hi

In this video we are taking a look at the Web Editor, which is used to view and modify how Leaptest captures web elements.

For a lot of cases, like clicking a button, setting focus in a field, entering a value, or assess if an image is present on a web page, you don’t have to worry about how the element is selected in Leaptest.

If you have a more complex application you might need to look at how the element is selected by Leaptest. First of all to ensure that you always get the right element, secondly it could be because of performance considerations if you have a complex web page and in some cases it make sense to use a more dynamic selection pattern – like always select the first article in a list of articles, no matter what the title and subject is.

I will illustrate the possibilities in a simple case.

I have a Start Web browser block and the URL is pointing to a web page containing a table.
You can find the URL (http://the-internet.herokuapp.com/challenging_dom) in the description of this video if you will try it out yourself.

I add a Find Web Element as the next block and click “capture new web element”. I capture one of the cells in the table.

When you capture a web element, Leaptest automatically finds some properties and values for the element, so the element can be uniquely identified when the test case runs.

Sometimes an element is uniquely identified by the text value in the element, sometimes by a CSS class and sometimes by the ID of the element itself. In most cases it’s a combination of values, that together uniquely identifies a web element. A combination of values that uniquely identifies an element is called a Locator Strategy – in short, just a Strategy.

When you capture a web element, Leaptest doesn’t just create one strategy for the element, but will typically produce a number of strategies, that you can select from.

To view the strategies, you click “edit web element” in the block, which opens the Web Editor. The Web Editor is used to handle advanced capture scenarios. We will look at some of them in this video.

We have a list all the strategies found by Leaptest in the left pane. Most strategies has a short description, which makes it easier to select the right strategy.
When you select a strategy you can see the details of the strategy in the right pane. These details are referred to as the Search conditions, or just the Conditions.

The first strategy says: “TD text equals Definiebas5”, which means that the strategy will look for a table cell, the TD, with the text “Definiebas5” inside. If we look at the Conditions, we can see that it includes the term “Self” followed by TD. “Self” means, that the strategy will look for any TD on the entire page independent of where it is located in the DOM. We will see other strategies a bit later that is based on the location of the TD in the DOM.

This strategy also contains a condition that the text property of the TD should equal “Definiebas5”, which means that the page only contains one TD with the text inside and the cell therefor is uniquely located by these 2 conditions.

If we look at the next strategy, we see a completely different approach. This strategy looks for a TD that has a TBODY as an Ancestor. Ancestor means that it doesn’t have to be a direct parent, but just in the hierarchy of parents. The page contains a lot of TDs that has the TBODY – which basically is the entire table – as an ancestor. But in this case, the strategy is looking for occurrence number 39 as stated in the “Use occurrence” field.

It can be a bit tricky to figure out if cell number 39 is the exact cell that should be selected. It usually easier if we could see the selected cell in the actual table, and luckily we have this option.

If we press Validate, the Web Editor will validate the conditions and show the selection in the browser with a red border. It will also show you the selected element in the DOM on the Web Tree tab. When we press Validate this tab will always get focus.

If I change the number in the “Use occurrence” field and press validate again, we can see that the red border is moved to another cell.

I press Reset to go back to the original definition of the strategy.

In the third strategy we see that it looks like strategy 1 crossed with strategy 2. In this strategy we are looking the a cell that contains the text from strategy 1, but now it also has to be within the TBODY tag from strategy 2.

The fourth strategy again uses another pattern that is worth understanding. The “Root-Descended-Child” strategy is solely based on parent-child relationships. In this case the strategy is looking for the 4th cell that is child to the the 6th row that is child of the TBODY in the page. This strategy is only using the positioning in the hierarchy of the DOM and doesn’t include any properties beyond this. So if you know that a result is always written to a specific cell,
this might be a good and fast strategy.

Let’s just select this fourth strategy and run the case.

  • Run case.

As we can see in the log and the video, the cell was found using the selected strategy. Let’s open the Web Editor again.

So far we have looked at all the predefined strategies and only changed very little in the conditions. But what would happen if we instead of capturing a cell wanted to capture an entire row. Well let’s try to capture a row. We can do this by clicking the Capture button, which is exactly the same
as pressing “Capture new web element” directly from the building block.

As you can see I can’t seem to capture the row. Every time I try, it highlights the cell instead. This is because the cell is covering the row and the capture tool can only access whatever element is at the top. To capture the row, what we could do, is to then capture a cell, select a strategy and then modify the strategy.

Let’s try to do this. I capture a cell, and then I find a strategy that includes the TR. In this case the “Root-Descended-Child”. I don’t need the TD so I click the delete button on this row. Then I click Validate to ensure that I now have selected a row. Looking in the browser, we now see row number 4 selected, so if I pressed Save now in the Web Editor, the Find Web Element block would return table row number 4 as the Found element.

If I want to see if there are any better strategies for selecting this row, I will have to make the row the “captured” element. I can do this by right clicking the highlighted TR in the Web Tree and select ‘Capture’. This is the exact same as if I was able to capture it directly in the browser, so we now have a list of strategies for selecting the table row no 4.

Let’s run then case

  • Run case

And as we can see, the Find Web Element located row number 4 as specified in the strategy.

In this video we covered the basics of the Web Editor and looked into what a locator strategy is.
We looked at the search conditions for some of the strategies and saw how we can change conditions
and validate the changes in the browser.

We also looked at how you can capture elements hidden from the visual capture tool using the Web Tree

Thank you.