Пагинация и фильтрация — основа работы с большим объёмом данных в API. Неправильная реализация может привести к багам: дубли, пустые страницы.
1. Проверка пагинации по limit/offset (или page/size)
Пример:
GET /api/users?limit=10&offset=20
Проверяем:
🔴 Количество записей соответствует limit
🔴 Первые записи не повторяются с предыдущими страницами
🔴 Последняя страница возвращает < limit элементов, если данных меньше
🔴 Указание offset больше общего количества — пустой массив, не 500
2. Проверка фильтрации по полям
Пример:
GET /api/orders?status=completed&userId=42
Проверяем:
🔴 Все записи в ответе соответствуют status=completed
🔴 Если указать несуществующий userId, получаем пустой массив
🔴 Несколько фильтров работают в связке (AND / OR)
🔴 Поля фильтра чувствительны к регистру или нет — по документации
3. Проверка сочетания пагинации + фильтра
GET /api/orders?status=pending&limit=5&page=2
Проверяем:
🔴 На каждой странице нет дубликатов
🔴 Фильтр не сбрасывается при переключении страниц
🔴 Количество записей соответствует фильтру, а не общему числу
4. Негативные сценарии
*️⃣ limit=-1, offset=999999 — должны возвращать ошибку или пустой массив
*️⃣ status=DROP TABLE — нет SQL-инъекций
*️⃣ limit=10000 — ограничение на максимальное значение (должно быть)
*️⃣ userId=abc — проверка валидации типов
5. Что важно проверить:
➖ Фильтрация отрабатывает точно — ни одной лишней или пропущенной записи
➖ Пагинация не ломает логику — нет дубликатов, всё делится корректно
➖ Ответ соответствует контракту API — есть поля meta.totalPages, items и т. д.
➖ API устойчиво к мусору — не падает на limit=-1, status=aaa
💡 Такие проверки особенно важны при работе с таблицами, админками, отчетами и логами. Пагинация + фильтры = зона, где чаще всего ломаются списки и появляются баги на проде.
🐸 Библиотека тестировщика
#буст