Pagination test cases about stability and cost

Unstable ordering produces the strangest bug reports you will receive. If the sort column is not unique, the database is free to return tied rows in a different order on every query, so a record shown on page one can appear again on page two while another is never shown at all. Users report missing data, and a single page test looks perfect. The fix is a unique tiebreaker on every sorted query.

A changing data set is the related problem. With offset paging, a record inserted at the top while the reader moves from page one to page two pushes one row down into the space they have already passed, so they never see it. On feeds that change constantly, cursor based paging is the correct answer rather than a nicety.

Page size is the security case. It looks like a preference and behaves like a parameter: uncapped, it lets anyone request the entire table in one request, which is both a performance risk and the easiest bulk extraction route in most applications. Cap it server side and reject anything above the cap rather than silently clamping.

Counts computed before permission filtering leak volume. The rows are filtered correctly but the total is not, so a user learns exactly how many records exist that they cannot see. Assert both the rows and the total against what that user is entitled to.