It is very common to come across web pages with multiple, functionally similar elements repeating on the screen.
For example, you may have a "Select" button against each flight option in the flight listing page of a travel portal. The "Select" button is repeating itself since every such button is functionally equivalent. The number of such buttons is also variable based on either the test data or the time of test execution. You may find a different number of "Select" buttons for flights between DFW and LON vs. those between ATL and JFK.
Your test logic requires you to select one of the flights, either randomly or based on some specific criterion, and move on to the next page.
When it comes to saving this element in the repository, it is not desired to find a locator that gives "uniqueness". This element should generically point to multiple instances of the same element on the screen. For example, if there are 20 Select buttons on the View, our element selector should point to 20 matches.
Example on a Car Search Results Page
Consider the example below with car Rental results. Every time you search for a car rental, you may get multiple options to choose from. The "Pay Now" button is a Repeat element, as it could occur any number of times and all such buttons are functionally equivalent.
Unique Match is not desired
By default, when you add an element to the repository, ACCELQ tries to find a locator for unique match. Here is how the default loctor may look like.
Notice it found a unique match for the element by utilizing an ancestor node (A3) as part of the locator. The "id" attribute for the element looks generic.
But since we know this is a Repeat element, we should try to bring the match-count to represent the multiplicity of the Pay Now button on the screen. Here is what the selector looks like with this modification. Notice that the matching buttons are highlighted on the View with orange-colored indicators.
Note: It is not necessary that the View you capture must have a display of all the Pay Now buttons. Even though the screenshot may be partial, we are still analyzing the match count against the entire DOM. Learn more.
It is important that the match-count exactly matches with the actual number of repeat elements that were present on the screen. It may require you to work with different combinations of attributes in the Element Explorer to end up with the right multiplicity.
Setting Repeat Index Policy
Once you mark an element as a Repeat element, you have a choice to select which instance number of this element you are specifically interested. You can leave it as "Random" if you aren't specifically interested in one of them.
You can choose from one of the policies below while saving the element, which can even be updated in your Action logic.
- Random: Points to a random instance of the element displayed on the screen when the test is running.
- First: Points to the first instance of the element on the screen.
- Last: Points to the last instance of the element on the screen.
- n-th from first: For example, 3rd Pay Now button.
- n-th from last: For example, Pay Now button which is 2nd from last.
Updating Repeat Index policy in Action logic
When you define an element as a Repeat element, the logic editor provides the ability to update the instance index to point to a specific element on the screen. In the element explorer, you may have chosen a specific or random ordinal index while defining the element. This can be changed while the test is running, based on defined logic. Following commands are available in Action logic.
Set Repeat Element by Ordinal Index
Updates the repeat element to point to an element instance at a given index. Note that the index starts from 1, which means the first instance of the element is indicated with index, 1.
Set Repeat Element by Text
Updates the repeat element to point to an element instance which contains given text. You may specify a regular expression pattern instead of a literal text, if required.
Set Repeat Element by Property
Updates the repeat element to point to an element instance which satisfies the given property/value combination.
It is common to build such logic for dealing with dynamic elements. At the time of setting up the element selector, some of the dynamic criteria are not known and hence these commands provide the flexibility to choose the exact criterion at the time of test execution.