На экране с несохранёнными данными Android возвращает системная кнопка «Назад», а iOS — жестом от края. Как проверить, что оба сценария используют одинаковую политику подтверждения выхода, а не только открывают один и тот же экран?
Проверяйте не только конечный экран, но и полный контракт навигации: появление подтверждения при несохранённых данных, отмену выхода, отказ от сохранения и поведение после сохранения. Один и тот же результат маршрутизации не доказывает одинаковую обработку системной кнопки Android и жеста возврата iOS.
Для каждого способа возврата нужно зафиксировать состояние данных до действия и проверить, что после отмены подтверждения пользователь остаётся на экране с неизменёнными данными, а после подтверждения выхода данные не сохраняются ошибочно.
Мобильные платформы изначально формировали разные модели навигации. На Android возврат обычно инициируется системной кнопкой, жестом или аппаратным действием «Назад», тогда как на iOS распространён возврат жестом от края навигационного экрана и кнопкой навигационной панели.
Эти действия проходят через разные механизмы навигационного стека и могут иметь различное поведение для модальных экранов, корневого экрана и интерактивного жеста. Поэтому приложение должно явно проверять бизнес-правило выхода, а не полагаться на совпадение визуального маршрута.
Если обработан только один способ возврата, пользователь может потерять введённые данные или обойти обязательное подтверждение. Особенно опасен интерактивный жест iOS: переход может начинаться до окончательного завершения навигации, поэтому проверка состояния только после завершения анимации способна пропустить ошибку.
Нужно учитывать чистое и изменённое состояние формы, отмену возврата, подтверждение выхода, сохранение данных и повторное открытие экрана. Также важно проверить корневой экран и модальные окна, где системное действие возврата может закрывать не навигационный экран, а текущую модальную оболочку.
Сначала определите единое правило: например, при наличии несохранённых изменений любой выход должен показать одно подтверждение; отмена должна оставить экран и данные без изменений; подтверждение выхода должно выполнить только предусмотренное действие.
Затем составьте матрицу входных действий:
Для каждого теста фиксируйте события, а не только визуальный результат: был ли вызван обработчик выхода, показано ли ровно одно подтверждение, изменилось ли состояние формы, был ли выполнен переход и сохранились ли данные.
Проверка должна выполняться на реальных или максимально близких к реальным системных механизмах навигации. Прямой вызов внутреннего метода закрытия экрана полезен для модульного теста, но не заменяет проверку системного жеста или кнопки: такой вызов может обойти платформенный обработчик.
Важное ограничение — нельзя требовать абсолютно одинаковой реализации на платформах. Android и iOS имеют разные визуальные паттерны и жизненный цикл жеста. Одинаковым должен быть пользовательский контракт и результат для данных, а не внутренний API навигации или длительность анимации.
В приложении форма редактирования корректно показывала подтверждение при нажатии кнопки возврата на Android. На iOS тестировщик проверил только завершённый жест от края и обнаружил, что при отмене диалога экран иногда уже удалялся из стека.
Рассматривались два варианта. Запретить жест полностью было проще и снижало риск потери данных, но ухудшало нативное поведение iOS. Обрабатывать только событие завершённого перехода было удобнее, однако оно происходило слишком поздно и не позволяло надёжно отменить интерактивный возврат.
Выбрали единый навигационный слой с предварительной проверкой несохранённых изменений и отдельными адаптерами для системных событий Android и iOS. Для iOS дополнительно проверяли отменённый интерактивный жест, а для Android — системный возврат и его повторное выполнение. В результате подтверждение появлялось один раз, отмена сохраняла форму на экране, а подтверждённый выход не записывал незавершённые изменения.
Как доказать, что проверяется именно системный возврат, а не обычная кнопка приложения?
Нужно инициировать действие средствами ОС: системной кнопкой или жестом Android, жестом от края на iOS. Если тест вызывает только общий метод навигации или нажимает пользовательскую кнопку, он не проверяет маршрутизацию платформенного события и может пропустить ошибку в адаптере навигации.
Что должно произойти, если пользователь начал жест возврата, но отменил его до завершения?
Экран и несохранённые данные должны остаться доступными, а подтверждение не должно приводить к частичному закрытию или повторному показу при следующем действии. Тестировать нужно как завершённый жест, так и жест, возвращённый назад до фиксации перехода, поскольку интерактивная навигация имеет промежуточное состояние.
Почему проверки только конечного экрана недостаточно?
Два сценария могут привести к одному экрану, но один из них способен преждевременно уничтожить состояние формы, дважды показать подтверждение или сохранить данные при отмене выхода. Поэтому результат теста должен включать состояние данных, количество показов подтверждения, факт выполнения перехода и поведение при повторном открытии формы.