# Working with Strategy Editor – Part 1

Learn how to use the Strategy Editor.

#### In this video

• How to use the Strategy Editor
• How to work with lists of elements
• How to use Variables and Tokens

Go to next video.

#### Lesson Overview

Learn how to use the Strategy Editor.

#### In this video

• How to use the Strategy Editor
• How to work with lists of elements
• How to use Variables and Tokens

Go to next video.

In this lesson we will take a first look at Strategy Editor and look at how we can view and modify the way Leaptest captures and identifies elements when the automation cases runs.

We will see how we can easily validate selections and how we can capture lists of elements. We will also see how to iterate lists of found elements and use variables/tokens to store data during an automation case.

Welcome to lesson 4 part 1 on desktop ui automation with Leaptest.

We have divided lesson 4 into 2 parts to make it a bit more digestible. In lesson 4 we are moving into an area which is a bit more complex
than what we have seen in the previous lessons, but also way more powerful.

We will look at how Leaptest actually captures elements and how the elements are found when the automation case is running. We will also look at how we can modify how elements are found and how we can capture and work with lists of elements. Finally we will introduce variables – or tokens – that we can use to store values in and reuse later in a flow.

We start out with something we seen before, which is the login block followed by a search for the word “ben”. If I run this, we will see that it returns 3 contact persons.

(Automation case runs)

The task here is to iterate through the contacts and sum up the value in the amount column regardless of the currency. At the end we will compare the sum to a predefined value and then pass or fail the case based on the comparison.

To get the individual rows I’m adding a Find UI Element block and select “Capture”. As we can see I can’t select the entire row, but only the individual cells in the grid. This is because the capture functionality will select the highest level control or field, which is the obvious choice in most situations. This also means that the individual cells is shadowing the row element that we want to select.

The way around this is to just capture one of the cells back into the block. Then we can open the Strategy Editor to change the actual selection, by clicking on the element and select “Edit element”.

The Strategy Editor can look a bit overwhelming at first but it’s actually not that hard to work with, once you get started. On the left we have a list of so called strategies, which are different ways of selecting the same element.

When you capture an element, Leaptest will not only generate one strategy, but actually create a number of strategies to select from. So if we for some reason prefer one way of finding an element over another, It’s easy to just pick the wanted strategy in this list.

The strategy it self, instructs the case how it should uniquely identify the element when the case runs. The instructions can be found on the right-hand side of the strategy editor, we call them the conditions. And as we will see later, we can not only select another strategy, but also change the conditions of a selected strategy. This is a very strong feature that makes it possible to do very complex operations in a relatively simple way.

In this selected strategy we select a cell in a grid – which we will change in a bit – but before we do this let’s have a look at the different strategies available to select this cell.

For the first strategy we can see that we have a hierarchy in the conditions. First we select the data-grid, then we select a row in the grid, and finally we select
an element containing the text we see in the actual cell.

If we select another strategy – we could take the one right at bottom of the list – we see a different pattern. The data-grid and the row is still the same, but now
the cell is selected by the position on the row. In this case it’s the first cell.

If we click “Validate”, the chosen strategy – including any changes to the conditions – will be executed on the already open application, and we will see a red rectangle highlighting the element that matches the conditions in the strategy. If we change the “Child no” to the value 2 and click validate, we now see that the second column is highlighted.

We can also delete elements from the hierarchy to change what element is selected. So if we delete the column part and the lowest level that just takes the text part of the column, and click “Validate”, we can now see, that the entire row is selected. So because we want to iterate the contact persons one row at the time,
this might be a good strategy.

What we have now is a strategy that selects only one row, but we want it to somehow select all the rows in the search result. If we examine the conditions a bit further, we can see that it says: “Child no”. This is the line telling the case to just select the first row. If we change the “Child no” to just “Child” it means that now all rows will be selected.

When we click validate now, we can see that it says “1 of 3”. This means the strategy matched 3 rows. If we click the arrow to the right we can see row 2 being now being highlighted, so this tells me that the strategy is now correct. It will select all the rows as a list of rows, that I can use inside my automation case.

When we click “Save”, the block will now use the selected and modified strategy and return a list of rows. As with all lists of data in Leaptest it’s easy to turn the building block handling the list into a looping block. We just select “All” in the “Use occurrence” field, which means that the top connector is now triggered for each element in the list, e.g. each contact person.

The “Found element” property will now contain the currently selected row, when all the rows are looped. To read the amount field, we attach a Get UI Number to the “Found element” property, and we can see that it’s connected to the “Source” property. This means the Get UI Number block will now only operate on the row and not the entire application.

We capture the “Amount” field from one of the rows, and then we just have to make a slight change to the strategy to read the number. The first strategy is based on the actual number in the amount field we captured. We want it to be able to read the amount field for any row, so we change to a strategy that is not based on the actual value in the amount field but select the field based on other conditions.

When we captured the “Amount” field, it was captured in the scope of the entire application. This means the conditions in the strategy contains the data grid and a reference to the row we captured from. Because we already have limited the scope to one single row by connecting the “Found element”
to the “Source” property, we don’t need the reference to the grid and the row, and can delete both these references.

To calculate the total amount we need to store the sum of the amount from the individual rows and update this as part of iterating the contact persons. To do this we add a “Set Variable” after we have fetched the amount value from a row. This block is used for creating variables or tokens that can be accessed during the case. We will name this “TotalAmount”, and we would like to set the value to whatever value we have already stored in the variable “TotalAmount” plus the value we just got from the current row.

To do this we add a Calculate block from the Logic category of building blocks to the “Number found” property. We then connect a “Get Variable” block to the “value B” property to read what value is already stored in the “TotalAmount” variable. The Calculation method is per default set to A+B, which means the Calculate block will return the sum of the two inputs. We then connect the “Result number” to the value property on the “Set Variable”.

So to summarize, we use a Find UI block to find and loop all the contact persons. For each contact person we read the Amount field and add this to a variable named “Total Amount”.

The last part of the test case is to verify that the calculated total amount is higher than a pre-defined value, and pass or fail the test case based on this. Once all the contact persons have been iterated, the “Completed” connector is now triggered and we can continue the flow from this connector. We add a Compare block to the connector and again use a “Get Variable” to read the “TotalAmount”. In this thought-up example we want to make sure that the total amount is greater than 40000, so we specify 40000 in the “value B” field, and select “Greater than” in the “comparison” method. If the value of “TotalAmount” is greater then 40000 then the Compare statement is correct and we will Pass the test case. If not, the test case will Fail.

Let’s run the entire test case.

(Automation case runs)

And the test case passed.

We can see in the log how the values from the individual rows are added to the TotalAmount variable, and that the value is used in the final compare.

In this video we looked into how Leaptest captures and finds the individual elements when the cases runs. We looked at the strategy editor and saw how we can select between different strategies and how we can modify the conditions behind the strategies to select lists of elements.

Using a modified strategy we collected data from a list of contact persons and used the Set and Get variable to store data while the flow was running.

This is the end of lesson 4 – part 1.