Какой ответ должен быть при запросе несуществующей страницы пагинации на бэке?

Что проверяют

Понимаете ли вы, что у этого вопроса нет единственного верного кода, а есть контракт API, который нужно проверить. Интервьюер ждёт, что вы разведёте случаи «страница за пределами данных» и «невалидный параметр». Следом спрашивают, какие тест-кейсы вы бы на это написали.

Как отвечать

Начните с того, что поведение определяет спецификация (OpenAPI, документация), а задача тестировщика проверить её соблюдение и единообразие по всем эндпоинтам. Дальше разберите варианты:

• страница за концом списка: запрос ?page=50 при трёх страницах. Чаще всего возвращают 200 OK с пустым массивом и метаданными вроде total и totalPages. Коллекция существует, просто в этом диапазоне пусто, и клиенту не нужна отдельная ветка обработки ошибки;
• ответ 404 Not Found: в той же ситуации тоже встречается и допустим, если так записано в контракте. Важно, чтобы его можно было отличить от 404 на несуществующий ресурс вроде /users/999;
• невалидный параметр: page=0, page=-1, page=abc это ошибка клиента, ожидается 400 Bad Request или 422 с понятным телом. Для limit сверх максимума допустимо молча урезать значение до лимита, если это описано;
• курсорная пагинация: испорченный или протухший курсор даёт 400, а конец данных определяется пустым next_cursor.

Для тест-кейсов берите граничные значения: первая страница, последняя, последняя плюс один, ноль, отрицательное, дробное, очень большое число, пустая коллекция. Проверяйте не только статус, но и тело, заголовки и то, что сумма элементов по всем страницам совпадает с total.

Где спотыкаются

Отвечают «конечно 404» без оговорок и не могут объяснить, почему пустой список тоже нормальный вариант.

Проверяют только статус и забывают про тело: 200 с ошибкой внутри JSON или 500 на page=abc это отдельные баги, и оба стоит заводить.

Не тестируют стабильность выдачи: без однозначной сортировки при добавлении записей элементы дублируются или пропадают между соседними страницами.