This tutorial demonstrates how one can deal with data held in HTML tables using the sample ATM application that can be accessed at http://www.inflectra.com/SampleATM.
For this example, let’s assume that the test engineer has to implement an automated test for the ‘ACCOUNT BALANCE’ page in the application:
This page has a table with several columns. Our goal is to validate it in the following way:
- Check that number of rows in it is more than 10
- Check that account #190001 belongs to Jess Smith
- Verify that Anette Dellatolas has maximum amount of Savings among all accounts
As we can see from these scenarios we will allow the table to be dynamic (i.e. the data in it may change). We don’t require the whole table to stay the same between different test executions. All we want is to make sure that certain table-wide properties are checked. For example, it is seen from the screenshot the number of data rows in the table is 12. But our goal is to know that it is more than 10, so once a couple of data rows are removed or added the test will stay valid.
Another important note here is that there are no assumptions about row order in a given table. All we need to know that certain rows are present (Jess Smith and Anette Dellatolas). But we are intentionally avoiding any assumptions about their order.
Static vs Dynamic Test
Now, Rapise allows you to easily check that certain cell in the table has certain value. One may simply use the ‘Verify’ feature and check a value of a specific table cell. This will allow us to easily build a simple and working test. However, this test will no longer work when something is added to the table. This kind of test is considered ‘Static’ since it assumes that the same cell always stays at the same position in the table. We do not recommend static tests when dealing with dynamic data stored in HTML tables as it makes your tests very “brittle” and not accommodating of change in the application.
Our goal therefore is to unlink the data value from its position in the screen. Anything may appear before or after ‘Jess Smith’ and the test should not start failing every time this happens. I.e. the test should allow dynamic data change and be focused on actual data rather than on its position. We call such data position change-friendly tests “Dynamic”. We recommend using Dynamic tests wherever possible and it makes your testing process more fluid and agile.
The first thing that we need to do is to record the steps necessary to reach the ‘ACCOUNT BALANCE’ page. The sample application requires users to sign on before reaching this page. So we need to create a new test, and record the login procedure:
You need to login with the sample user – email@example.com password = rapise.
Next, click on ‘BALANCE’ button:
And that will take us to the screen that displays the balance table: