Table-style UIs such as list screens and search result screens are components that frequently appear in web applications. However, there are many situations that require careful thought when implementing tests, such as when the number of rows changes dynamically or when the same operation needs to be repeated for each row.
This page covers three common scenarios when testing tables — "clicking a specific button in every row", "verifying that X rows are displayed", and "clicking an element in a specific row regardless of display order" — and introduces how to implement them using MagicPod's features.
Table of contents
- Clicking a specific button in every row
- Verifying that X rows are displayed
- Clicking an element in a specific row regardless of display order
Clicking a specific button in every row
Using Repeat Until & Conditional commands
If the maximum number of rows in the table is known, this can be implemented using the repeat until commands and the conditional commands.
For example, suppose you have a product list app where the table has a maximum of 20 rows, and you want to click the Details button in every row.
Change the Details button locator to one with a variable
First, change the Details button locator to one that includes a variable called "row number".
XPath locator: (//button[text()='Details'])[${row number}]
Reference: Add/Edit a locator
Add Repeat Until & Conditional commands
Next, set up the following steps:
Set the initial value of the variable "row number" to "1" by using Store fixed value command
- Repeat the following process until "row number" reaches 20:
- Check whether the "Details" button is visible on screen
- If it is visible:
- Click the "Details" button
- Click the "×" button on the detail screen that opens
- If it is visible:
- Use the Arithmetic operation command to increment the "row number" variable by 1
- Check whether the "Details" button is visible on screen
Reference: Repeat Until command Utilize conditional branching
Using the "Assert all links on the page are valid" command
If the purpose of clicking every button in each row is to check for broken links, you can use the "Assert all links on the page are valid" command.
This command asserts that all visible links (anchor elements) on the page are not broken. Links are considered "broken" if the HTTP status code of the destination is anything other than 200/300-range.
Reference: Assert all links on the page are valid
Verifying that X rows are displayed
Using a locator that includes row count information
One approach to verifying the number of displayed rows in a table is to use XPath locators.
Verifying that the number of displayed rows matches expectations
For example, to confirm that 3 rows are displayed in a table, use a locator that targets a cell in the 3rd row and verify that the element is "visible."
XPath locator: (//tbody)[1]/tr[3]/td[1]
This locator targets the 1st cell of the 3rd row within the first <tbody> on the page. If this element is visible on screen, you can confirm that at least 3 rows exist.
Verifying that the number of displayed rows does not exceed expectations
To confirm that no more than 4 rows are displayed, use a locator targeting a cell in the 4th row and verify that the element is "not visible."
XPath locator: (//tbody)[1]/tr[4]/td[1]
This locator targets the 1st cell of the 4th row within the same first <tbody>. By confirming that this element does not exist (is not visible) on screen, you can verify that the table does not have 4 or more rows.
By combining these two conditions — "the 3rd row is visible" and "the 4th row is not visible" — you can confirm that exactly 3 rows are displayed in the table.
If the row count varies and you want to change the locator value each time, make use of locators with variables.
Reference: Add/Edit a locator
Using AI Assertions
You can use the "Verify with AI" command to check the row count using generative AI.
Example prompt:
Verify that 3 rows of data are displayed in the product list table
If you also want to check elements that appear after scrolling, insert a scroll command and run multiple AI assertions as shown below.
Reference: AI Assertion
Using Visual diff checks
For more rigorous verification of the number of displayed rows, image diff checks are recommended. If the displayed content changes each time, you will need to use workarounds such as setting exclusion areas. Please refer to the help page for details.
Reference: Visual diff checks
Clicking an element in a specific row regardless of display order
Using a locator that contains information identifying the row's content
In the product list shown below, suppose you want to click the "Details" button on the "Strawberry" row, but the row order may change with each test run.
In this case, if the product name is unique and does not duplicate across rows, you can handle this by using a locator that includes the product name.
XPath locator: (//tbody)[1]/tr[td[text()='Strawberry']]//button[text()='Details']
You can also store the product name in a variable in advance and specify clicking the "Details" button on the row matching that product name.
XPath locator: (//tbody)[1]/tr[td[text()='${Product Name}']]//button[text()='Details']
Reference: Add/Edit a locator