Автор: Эш Уинтер (Ash Winter)
Оригинал статьи
Перевод: Ольга Алифанова

Службы геолокации: критичны для функциональности, сложны для тестирования

Недавно я работал над мобильным приложением, бросившим тестированию настоящий вызов. Это приложение работало в фоне, используя службы геолокации. Пользователь часто держит телефон в кармане, занимаясь своими делами. Приложение генерирует советы для пользователей на основании посещенных ими мест.

Тестирование отслеживающих местоположение приложений может занимать много времени, так как тестировщику необходимо перемещаться так же, как реальному пользователю. На имитаторы и подмену геолокации полностью полагаться нельзя – нужно тестировать и в живой природе. К тому же надо учитывать множество различных конфигураций – у ряда устройств отслеживание геолокации идет по WiFi-точкам.

Короче говоря, для качественного тестирования приложения нужно улучшать его тестируемость.

Улучшение тестируемости: модель «Контролируемость, Наблюдаемость, Декомпозируемость и Простота» (CODS)

Говоря о тестируемости, важно опираться на некую модель. Мой друг Роб Мини создал модель «Контролируемость, Наблюдаемость, Декомпозируемость и Простота» (CODS).

• Контролируемость: способность контролировать систему, воспроизводя любое из важных состояний.
• Наблюдаемость: способность наблюдать за всеми важными элементами системы.
• Декомпозируемость: способность анализировать систему, как набор компонентов, тестируемых независимо.
• Простота: простота системы для понимания.

Предложите команде начать пользоваться этой моделью еще до того, как написана первая строчка кода. На этом этапе заложить тестируемость куда легче.

Я подробно опишу ряд улучшений, внедренных нами в приложение по ходу его создания. В нашем случае мы начали с декомпозируемости, потому что возможность тестировать каждый компонент независимо дает нам наиболее раннюю обратную связь.

Декомпозируемость на практике: выбор сторонних библиотек и создание специализированных интерфейсов

На основании опыта своей команды я предлагаю вот что:

• Тщательно изучите вопрос. Популярность – это еще не все, но в случае сторонних библиотек она о чем-то говорит. Для начала ищите те, где больше пользователей и выше рейтинг. Более того, библиотека должна активно поддерживаться, что часто видно по недавним исправлениям проблем и солидным юнит-тестам. Стоит присоединиться к форуму, посвященному этой библиотеке, если он существует. И не забывайте о вежливости, особенно если у библиотеки открытый исходный код.
• Создайте свои собственные интерфейсы. Тут на сцену выходит декомпозируемость. При помощи специализированных интерфейсов вы сможете добавить высококачественные логи. Хороший, инструментальный интерфейс поможет также выявить баги в общении сторонней библиотеки с вашей бизнес-логикой.

Если вы, как тестировщик, можете участвовать в обсуждении использования сторонних библиотек и архитектуры интерфейса, тестировать будет намного проще.

Контролируемость на практике: настройка состояний приложения

Легко представить, как многолико приложение, зависящее от отслеживания местоположения. Передвижение на машине, а не пешком, долгая остановка с потерей позиционного сигнала, проезд через тоннель – это лишь несколько примеров. Странных моментов будет очень много. Тестированию крайне пригодится сбор обратной связи с вашего устройства. Да, ее применение ограничено, особенно при локализации багов, потому что бесконечное количество возможных точек сильно усложняет воспроизведение найденных проблем. Когда вы отчитываетесь о сложных в воспроизведении багах, это не улучшает ваших отношений с разработкой.

Для тщательного тестирования кода надо иметь возможность задать приложению любое из его важных состояний. Это требует контролируемости. Вам понадобятся инструменты, а в мире геолокационных служб файлы GPS Exchange Format (GPX), содержащие остановки и маршруты – то, что доктор прописал.

Нам нужно было:

• Рисовать маршруты на карте, чтобы имитировать движение устройства.
• Симулировать остановки различной длительности в разных местах.
• Экспортировать маршруты и остановки в GPX-файлы, чтобы прикрепить их к баг-репортам.
• Импортировать и исследовать GPX-файлы, сгенерированные на устройстве в ходе

перемещений.

Чтобы улучшить тестирование, мы пользовались тремя типами инструментов:

• Инструменты виртуализации геолокации
• Редактор GPX-файлов
• Инструменты GPX, установленные на тест-устройствах.

Пользуясь таким набором, мы легко делились информацией о багах и исследовательском тестировании. Ключевым фактором были данные, сгенерированные физическим устройством, а затем мы могли воспроизводить конкретные сценарии, используя специализированные GPX-файлы.

Наблюдаемость на практике: сбор информации о службах геолокации

Контролируемость и наблюдаемость – две стороны одной медали. Вам нужно иметь возможность видеть, настроили ли вы нужное состояние в приложении. Также надо знать, что происходит, когда вы переходите из состояния в состояние.

Наблюдаемость сейчас широко обсуждается, а подходящие инструменты варьируют по цене и сложности. Изучите вопрос, прежде чем тратить деньги.

Мы внедрили ряд паттернов:

• Классификация важных событий. Мобильные устройства генерируют множество записей в лог. Библиотеки отслеживания местоположения также генерируют прорву информации в режиме дебага. Очень легко потерять важную информацию просто из-за ее масштабов.

Чтобы этому препятствовать, пронумеруйте все важные события, дав им уникальные идентификаторы и читабельные имена:

{
NotSet = 0
NotInitialised = 10000,
Initialised = 10001,
NotAuthenticated = 20001,
Authenticated = 20002
}

Для нашей команды просмотр логов также стал отличным упражнением, чтобы разобраться, где нам вообще нужны эти логи.

• Выберите централизованный инструмент логирования. Так как вы будете часто перемещаться, вам придется сохранять логи с вашего устройства. Все устройства должны логироваться в один и тот же инструмент. Поиск паттернов внутри логов от многих устройств помогает поместить найденные проблемы в контекст. Если проблема воспроизводится на нескольких устройствах, это, вероятно, заслуживает более глубокого изучения. Мы пользовались Bugfender, но есть и другие доступные инструменты.
• Добавьте скрытое меню разработчика. Помимо экспорта логов в централизованное место, важно видеть, что происходит на самом устройстве. Для этого мы добавили специальное подменю, хорошо спрятанное на экранах «О приложении». Оно позволяло получать данные от устройства, находясь «в поле». Для начала мы добавили возможность получить список локаций, в которых устройство побывало, и длительность каждой остановки. По мере развития тестирования мы добавляли в это меню другие вспомогательные опции.

Простота на практике: оптимизация тест-автоматизации служб геолокации

Автоматизация тестирования мобильных приложений – задача сложная, и усложняется еще сильнее, если запускается в пайплайне. Приложения так же должны работать в фоне. А если для любого иного тестирования применяются эмуляторы, на их геолокационные данные нельзя полагаться. Упрощайте: концентрируйтесь на юнит-тестах и компонентных тестах, они гораздо надежнее. Осмотрительно добавляйте end-to-end тесты.

Сконцентрируйтесь на трех областях:

• Правильно инициализируйте свою библиотеку отслеживания местоположения. Как правило, вам нужна аутентификация, разрешения устройства, настройки точности геолокации и текущая локация. Правильная настройка сделает процесс тестирования более гладким.
• Отслеживайте изменения контракта между интерфейсом и библиотекой. Чем позже вы обнаружите изменения контракта, тем дороже вам это выйдет.
• Убедитесь, что интерфейс правильно обращается с бизнес-логикой.

Помните об этих аспектах, автоматизируя тестирование, и избежите множества проблем. Учитывая, что сборка мобильного приложения занимает много времени, очень важно беречь время тестирования.

Заключение

В ходе тестирования мы нашли множество интересных проблем. Один из моих любимых скрытых, но разрушительных багов был связан с тем, что устройства автоматически экономили расход батареи, ограничивая отслеживание геолокации.

Тестирование мобильных приложений может быть наисложнейшим, потому что они полагаются на фоновые процессы – например, на службы геолокации. Улучшение тестируемости жизненно важно для качества тестирования. Благодаря модели «Контролируемость, Наблюдаемость, Декомпозируемость и Простота» (CODS) у нас есть отличный фреймворк, ведущий нас по пути оптимальной тестируемости.

Обсудить в форуме