 |
How to automate testing tables
When automating tables you want to make sure you use the most stable and the easiest way to do it.
Specifically, there are two most reliable ways to do it:
- When working with tables rely on relative locations
- When working with tables rely on table structure from an end-user’s perspective
For example, if we are to delete a row in a table described here:
| # | Id | Name | Actions | Additional Data |
|---|---|---|---|---|
| Filter by | ||||
| 101 | york1 | Yorktown | ||
| 102 | spk2 | Spock | ||
| 103 | nyo3 | Nyota |
by clicking on the “delete” button on the row with the unique id “spk2”
We can express clicking on the button using relative location in testRigor like this:
click on the second button to the right of "spk2"
Or, we can use table language to express the context where to find the buttons like this:
click on the second button within the context of table at row containing "spk2" and column "Action"
Both ways would work even if the rendering of the table change from table-based rendering to div-based rendering like this one.
Compare it with a way of doing it in Selenium: you’d have to build an XPath to locate the element, that in the case of the first table you’ll build the XPath like this:
//table/tbody/tr[td[text()="spk2"]]/td[3]/a[2]
however, it will fail if engineers would migrate to a library that renders the table using divs like so. And the XPath will not only change dramatically like so:
//*[@id="table3"]/div/div/div/div/div[2]/div[2]/div[4]/a[2]
but also, there is barely any reliable way to refer to that element using XPath at all.
Here is a video walking through step by step how to do it:
Would you like to try it yourself?
You can get a forever free account here.
