Mock LocationТестирование геолокации: подмена координат для QA и разработчиков
Геозависимая логика — один из самых неудобных объектов тестирования: баг воспроизводится в конкретной точке города, а команда сидит в другом. Подмена местоположения превращает такую проверку в повторяемый сценарий, который прогоняется с рабочего места столько раз, сколько нужно. Разберём, как это устроено на реальном устройстве и где проходят границы применимости.
Подготовьте устройство
Включите режим разработчика, выберите приложение для фиктивных местоположений и выдайте ему доступ к геолокации. На тестовых устройствах имеет смысл сразу снять ограничения фоновой работы — иначе прошивка будет выгружать сервис в середине долгого прогона.
Заведите набор эталонных точек
Сохраните в избранном координаты, которые нужны регулярно: адрес из баг-репорта, точка на границе зоны доставки, адрес в другом часовом поясе, точка посреди воды. Именованный список воспроизводимых точек — основа повторяемости прогонов.
Синхронизируйте набор с командой
Список мест синхронизируется между сайтом и устройствами через аккаунт: точки, заведённые на сайте, появляются на тестовых телефонах сразу, без ручного переноса координат. Это заметно экономит время, когда устройств несколько.
Прогоните сценарий и зафиксируйте результат
Включите подмену в нужной точке и выполните проверяемый сценарий в тестируемом приложении. Точка остаётся в истории, поэтому вернуться к ней при повторной проверке после исправления можно одним нажатием.
Что проверять обязательно
Границы зон: точка ровно на границе зоны доставки или радиуса поиска — классический источник ошибок «на единицу». Смена координат в процессе работы приложения: многие приложения запрашивают местоположение один раз при запуске и не реагируют на его изменение. Отсутствие координат: поведение при выключенной геолокации и при отказе в разрешении.
Отдельно — заведомо некорректные данные: точка посреди океана, координаты в другом полушарии, места без адресной привязки. Приложение не должно падать ни на одном из этих случаев.
Реальное устройство против эмулятора
Эмулятор Android Studio умеет задавать координаты и проигрывать маршруты, и для ранней разработки этого достаточно. Но он не воспроизводит того, что ломается чаще всего: поведение конкретной прошивки при выгрузке фоновых сервисов, работу при слабом сигнале, реальные задержки получения фикса и различия вендорских политик энергосбережения.
Поэтому сценарий, прошедший на эмуляторе, стоит перепроверять на реальном устройстве — особенно если тестируемое приложение работает с геолокацией в фоне.
Флаг фиктивного источника в тестировании
Android помечает координаты от тестового провайдера служебным признаком. Для QA это не помеха, а отдельный объект проверки: если тестируемое приложение обязано отклонять фиктивные координаты, то подмена — как раз способ убедиться, что проверка действительно работает, а не просто написана.
Если же приложение должно принимать любые координаты от системы, убедитесь, что оно не отбрасывает их по этому признаку случайно.
Проверка приложений с фоновой геолокацией
Для приложений, отслеживающих перемещение в фоне, важны длинные прогоны: включить подмену, свернуть приложение и оставить устройство на несколько часов. Так проявляются проблемы, которых не видно за пять минут ручной проверки, — потеря подписки на обновления, накопление ошибок, остановка сервиса прошивкой.
Постоянное уведомление в шторке служит индикатором: пока оно на месте, подмена активна.