Автоматизируйте UI-тесты

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

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

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

Инструментированные тесты пользовательского интерфейса в Android Studio

Чтобы запустить инструментированные тесты пользовательского интерфейса с помощью Android Studio, вы реализуете свой тестовый код в отдельной тестовой папке Android — src/androidTest/java . Подключаемый модуль Android для Gradle создает тестовое приложение на основе вашего тестового кода, а затем загружает тестовое приложение на то же устройство, что и целевое приложение. В своем тестовом коде вы можете использовать платформы тестирования пользовательского интерфейса для имитации взаимодействия пользователя с целевым приложением, чтобы выполнять задачи тестирования, охватывающие конкретные сценарии использования.

Фреймворки Jetpack

Jetpack включает в себя различные платформы, предоставляющие API для написания UI-тестов:

  • Платформа тестирования Espresso (Android 4.0.1, уровень API 14 или выше) предоставляет API для написания тестов пользовательского интерфейса для имитации взаимодействия пользователя с представлениями в одном целевом приложении. Ключевым преимуществом использования Espresso является то, что он обеспечивает автоматическую синхронизацию тестовых действий с пользовательским интерфейсом тестируемого приложения. Espresso определяет, когда основной поток простаивает, поэтому может запускать тестовые команды в нужное время, повышая надежность ваших тестов.
  • Jetpack Compose (Android 5.0, уровень API 21 или выше) предоставляет набор тестовых API для запуска и взаимодействия с экранами и компонентами Compose. Взаимодействия с элементами Compose синхронизированы с тестами и позволяют полностью контролировать время, анимацию и рекомпозицию.
  • UI Automator (Android 4.3, уровень API 18 или выше) — это платформа тестирования пользовательского интерфейса, подходящая для функционального тестирования пользовательского интерфейса между приложениями в системе и установленных приложениях. API-интерфейсы UI Automator позволяют выполнять такие операции, как открытие меню «Настройки» или средства запуска приложений на тестовом устройстве.
  • Robolectric (Android 4.1, уровень API 16 или выше) позволяет создавать локальные тесты, которые запускаются на вашей рабочей станции или в среде непрерывной интеграции в обычной JVM, а не на эмуляторе или устройстве. Он может использовать API-интерфейсы тестирования Espresso или Compose для взаимодействия с компонентами пользовательского интерфейса.

Нестабильность и синхронизация

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

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

Тестовая синхронизация

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

блок-схема, показывающая цикл, который проверяет, простаивает ли приложение, перед выполнением теста
Рис. 1. Тестовая синхронизация.

Чтобы повысить надежность вашего набора тестов, вы можете установить способ отслеживания фоновых операций, например Espresso Idling Resources . Кроме того, вы можете заменить модули для тестовых версий, которые можно запросить на предмет бездействия или которые улучшают синхронизацию, например TestDispatcher для сопрограмм или RxIdler для RxJava.

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

Архитектура и тестовая установка

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

Изготовление и тестирование архитектурных схем. На производственной диаграмме показаны локальные и удаленные источники данных, передающие данные в репозиторий, который, в свою очередь, асинхронно передает их пользовательскому интерфейсу. Диаграмма тестирования показывает поддельный репозиторий, который предоставляет свои данные синхронно с пользовательским интерфейсом.
Рисунок 3. Тестирование пользовательского интерфейса путем замены его зависимостей поддельными.

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

Зачем проводить автоматическое тестирование?

Приложение Android может быть ориентировано на тысячи различных устройств с разными уровнями API и форм-факторами, а высокий уровень настройки, который ОС предоставляет пользователю, означает, что ваше приложение может отображаться неправильно или даже аварийно завершать работу на некоторых устройствах.

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

  • Уровень API : 21, 25 и 30.
  • Язык : английский, арабский и китайский.
  • Ориентация : Портрет, пейзаж.

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

Дополнительные ресурсы

Для получения дополнительной информации о создании тестов пользовательского интерфейса обратитесь к следующим ресурсам.

Документация

Кодлабы