Pagination bugs often hide behind a successful first page. The first “load more” request works during a demo, but a retry, duplicate item, or changed filter later produces missing cards or mixed results.
Use a small artificial catalog so you know exactly what each page should contain. It is easier to reason about six controlled records than a changing public result set.
Give the fixture difficult edges
Make page two repeat the last ID from page one. Give two different records the same title. Return a final page with no next cursor. Add one response where optional metadata changes for an already loaded ID.
Pass the documented cursor unchanged in the next request. Your test should notice if the client invents an offset or reuses a cursor after changing the query or sort.
Delay the second page, change the filter, and let the old response arrive. Only the new search's results should remain. Then fail a page request and retry it. The list must not skip the failed page or append its records twice.
Check the interaction boundary
Prevent concurrent duplicate loads from a rapid double click or a scroll observer firing repeatedly. Keep the loading indicator attached to the next-page action while preserving already available cards.
If the app restores search after navigation, verify that its accumulated records and next cursor belong to the same search state. Restoring one without the other can create a hard-to-reproduce gap.
These fixtures test the client's list model, not the quality of search ranking. Keep a separate real contract check for the provider's response shape so your mock cursor design cannot silently replace the documented API.