🐴 Дело о последней странице
На первый взгляд пагинация работает идеально. Открываем список.
Переходим на вторую страницу.
Там свои записи.
Возвращаемся назад — всё на месте. Но что произойдёт, если данные изменятся между переходами по страницам? Например, у нас 41 объект и по 20 объектов на странице. Первая страница: 1–20 Вторая: 21–40 Третья: 41 Теперь удаляем один объект с первой страницы. Объектов осталось 40. Третья страница больше не должна существовать. Но если интерфейс продолжает считать, что страниц три, пользователь может попасть на пустую страницу. А бывает интереснее. Добавили или удалили несколько объектов — и записи начинают:
повторяться на соседних страницах;
пропадать;
перескакивать между страницами;
отображаться не в том количестве;
исчезать после обновления. И вот здесь возникает вопрос: как вообще тестировать пагинацию, если данные в списке постоянно меняются? Недостаточно проверить: «Есть 20 элементов → нажал “Следующая страница” → увидел следующие 20». Стоит менять данные между запросами. Например: — удалить элемент с первой страницы;
— добавить новый элемент;
— удалить последний элемент последней страницы;
— изменить сортировку;
— применить фильтр после перехода на другую страницу;
— открыть одну и ту же выборку в двух вкладках;
— проверить, что происходит, когда последняя страница после изменения данных исчезает. И отдельно посмотреть на API: page, offset, limit, total, сортировку. Потому что проблема может находиться не в самой кнопке «Следующая», а в том, как сервер формирует выборку после изменения данных. Пагинация — хороший пример проверки, где важно тестировать не только действие пользователя, но и изменение состояния данных между действиями.
🐴 Корс. Дело о последней странице.
