Занимаясь разработкой мобильных приложений под операционную систему Android уже более 7 лет, я успел поработать в разных частях мира в самых разных компаниях, от небольших стартапов, где я был единственным мобильным разработчиком, до технологических гигантов с тысячами инженеров. За это время я накопил некоторый практический опыт в области автоматизированного тестирования мобильных приложений, которым хотел бы поделиться в цикле статей.
На одном из моих первых коммерческих проектов, в какой-то момент код и команда дошли до такого уровня, когда затраты на написание и поддержку тестов начали себя окупать. Однако, тогда еще было не так много доступных статей и докладов на эту тему в открытом доступе. И до простых вещей приходилось доходить не самыми прямыми и простыми путями, порой делая глупые ошибки.
Несмотря на то, что сейчас литературы стало в разы больше, я хотел бы продемонстрировать на практическом примере, как можно организовать проект и тесты для него.
В качестве примера, будет выступать простейшее приложение, состоящее из пары экранов, для отображения погоды. На момент написания данной статьи оно состоит из 2 экранов. На одном из которых пользователь выбирает интересующее местоположение, и на втором – непосредственно отображается сам прогноз. Для простоты, список мест прописан в самом приложении, и для демонстрации работы с сетью, данные о погоде подгружаются из открытого источника.
Чтобы было проще ознакомиться с примерами и структурой проекта, исходный код выложен на GitHub. Некоторые примеры могут вызвать вопросы, и это ожидаемо, поскольку в реальном проекте не всегда удается уделять достаточное количество времени и ресурсов для написания и поддержки тестов, и мы, как инженеры, в первую очередь должны думать о том, какую пользу приложение и наш проект приносят бизнесу и конечному потребителю, что порой заставляет нас идти на некоторые компромиссы. Надеюсь раскрыть все такие моменты в последующих статьях.
Структура проекта, программное обеспечение и тесты для него должны быть неотъемлемой частью стратегии тестирования. Глобально, стратегия тестирования — это принятая в организации схема, описывающая подход к тестированию цикла разработки программного обеспечения. Цель такой схемы состоит в том, чтобы преобразовать высокоуровневые требования организации (заказчика) в набор конкретных подходов и процедур, которые позволят достичь требуемый уровень качества сервиса.
Стратегию тестирования следует создавать и документировать систематически, чтобы гарантировать, что все цели полностью охвачены и понятны всем заинтересованным сторонам. Хорошей практикой является регулярный возврат к этому процессу для пересмотра и внесения возможных улучшений, либо изменений по мере развития продукта, организации и индустрии в целом.
Важной частью тестовой стратегии являются автотесты.
Существует большое разнообразие тестов и способов их классификации. Для мобильных разработчиков, наиболее применимые способы включают в себя классификации по:
Предмету (объекту) тестирования:
Функциональное тестирование;
Тестирование производительности;
Тестирование корректности поддержки специальных возможностей (accessibility);
Тестирование совместимости;
По масштабу/рамкам (scope)
Модульное (unit) тестирование;
Интеграционное тестирование;
Сквозное (e2e) тестирование;
По среде выполнения тестов
Локальные тесты;
Инструментальные тесты.
Остановимся подробнее на классификации по скоупу тестирования. Наверняка каждый знаком и не раз встречался с пирамидой автоматизированного тестирования.
Данная пирамида позволяет подчеркнуть особенности и достоинства каждого из уровней. Считается, и в большинстве своем это именно так, что чем ближе к основанию на этой схеме расположен тест тем меньше времени требуется на его написание и запуск. Чем выше на схеме расположена категория, к которой относится тест, тем больше ресурсов требуется на его разработку, поддержку и прогон, но и тем больше информации о системе дает успешно пройденный тест. (Компоненты могут безупречно выполнять свою работу, но быть совершенно несовместимы друг с другом, компоненты могут быть совместимы, но работать некорректно в реальной, а не симулированной среде). Существует мнение, что данная форма также отображает количественное распределение тестов по категориям, и чем больше площадь блока категории на схеме, тем большее количество тестов должно быть в проекте (т.е. юнит текстов побольше, а e2e тестов поменьше). Заранее скажу, что не считаю, что следует всегда следовать этому правилу, и есть ряд условий (например текущий этап развития и изначальные цели проекта), когда оправдано следовать другому способу распределения.
Есть много информации, которую хотелось бы раскрыть про каждый уровень, и всегда ли эти уровни образуют пирамиду (спойлер - не всегда) и, так как я считаю, что усваивать информацию проще небольшими порциями, поговорим о них в отдельных статьях.
