Handle tables with pagination

How can I count the table rows through multiple pages “pagination”? I can count the table rows in the current page but I can’t count all rows if there multi pages

It may be possible to use a while loop to “page” through your multiple pages and continue to keep count of the table rows. The while statement would contain the counting table rows routine. You would need some condition, or indicator, that you have reached the last page, where upon you would set your while condition to end the loop.

e.g.

boolean hasFound = false;
GlobalVariable.gRowCount = 0;

while (!hasFound) {
   myRowCountRoutine()
   if (condition == 'End') {
       hasFound = true;
   }
}
WebUI.comment("My row count is ${GlobalVariable.gRowCount}")

This assumes there is some means, such as a “Next” button, to move to another page.

There are a couple of ways to do it. One is as @grylion54 said: loop through all of the pages and keep count of the number of rows.

Another possibility is that the particular table implementation has a count of the rows in the HTML. If you could provide a screenshot of the <table> element for your table, and maybe some of the surrounding elements, we could check.

I guess it has to be me to stick my head above the parapet and wave the end-user /automation testing flag.

Highly opinionated statement 1: You should not do this.

Highly opinionated statement 2: Nobody should do this.

If there are no unit tests to ensure pagination code is working correctly, you should not be the one to cover this situation by adding code like this to your UI automation tests. Ask yourself, “Is what I am about to do, something a user would do?” If not, stop what you are doing and rethink what a user is expecting from the UI.

Having said all of that, the following ARE reasonable tests:

// Ensure rows do not exceed pagination size
// Count the number of rows --> N
// Delete one row 
// Check number of rows == N-1
// Ensure row count is at least 2 less than pagination size
// Count the number of rows --> N
// Add new row 
// Check number of rows == N+1
// Ensure row count equal to pagination size
// Count the number of rows --> N
// Check number of rows equal pagination size
// Check pagination code offers only ONE page
// Add new row 
// Check number of rows still == pagination size
// Check number of rows still == N
// Check pagination code offers TWO pages
// Move to page TWO
// Check page TWO has only ONE row

I could go on, checking more deletes and ensuring the pagination works as a user might expect. But I’ll leave that for you :wink:

While no user would ever construct a query to return them all, our customers deal with tens of millions of rows – it’s indeed possible that a query could paginate that many rows. There is NO WAY I would or even could write a test as you have described. My advice, go back to your boss and explain why it’s better for you - and THEM – that you write tests incorporating everyday user actions that cover user expectations. No more. No less.

</rant>

Preparing for the barrage… :upside_down_face:

Well OP never said they were doing this in an attempt to test the functionality of the pagination itself. All we know is that they want to count the total number of rows in the table, and that the table is paginated. If the purpose of the test is to validate that pagination is working correctly, and that pagination is a third-party implementation, then I agree with @Russ_Thomas. However, we don’t have enough information to assume this is the case.

1 Like

I think it’s pretty clear OP wants all of them.