Продолжаем разбираться с автоматизацией Android проекта на GitHub Actions, в этой части:  Заведем новый проект под UI-тесты в Firebase Test Lab Настроим интеграцию GitHub Actions и Test Lab Посмотрим, как можно запускать UI-тесты в workflow на CI/CD.   Если пропустили первую часть рассказа, где разбирались с Unit-тестами в Android проекте, можно начать с нее. Чтобы запустить unit-тесты, нам достаточно иметь настроенное Java-окружение. Все тесты проходят очень быстро внутри JVM, всё просто, и почти исключена ситуация появления flacky-тестов. Таких тестов должно быть 70-80% от общего количества тестов в проекте, в первую очередь стоит покрывать ими бизнес-логику. Но иногда хочется большего – тестов, которые будут имитировать действия реальных пользователей и сверять ожидания с реальностью. С UI-тестами всё непросто с самого начала. Во-первых, их нужно написать. Звучит банально, но уже на этом этапе у большинства заканчивается энтузиазм. Потом, когда критическая масса UI-тестов написана, нужно придумать, как это богатство запускать и поддерживать в рабочем состоянии в условиях постоянных А/Б-тестов и частых изменений интерфейса. Нужно решать, где они будут запускаться - реальные устройства или эмуляторы и кто будет владеть этими устройствами - своя ферма телефонов или пользоваться услугами сторонних сервисов. В общем, тема не из лёгких. Мы пойдем по самому простому и удобному пути - Firebase Test Lab Firebase Test Lab - это сервис от Google, предоставляющий возможность запускать тесты на реальных устройствах или эмуляторах. На момент написания поста бесплатный тариф предлагает 10 тестов в день на эмуляторах и 5 на реальных устройствах. В платном тарифе цена сейчас 1$ за телефоно-час эмулятора, можно и заплатить за такое удобство. Весь процесс запуска тестов в Test Lab можно описать следующими шагами: Делаем checkout на нужный коммит и устанавливаем Java-окружение Проводим unit-тестирование. Если на этом шаге ошибка, то нет смысла тратить время на UI-тестирование. Собираем специальными Gradle-тасками артефакты для UI-тестирования Выкачиваем APK-артефакты, которые собираемся отправить на тестирование. Авторизуемся в Firebase Test Lab с помощью персонального токена. Используя специальную command line утилиту gcloud, скармливаем в Test Lab собранные ранее APK. Ждём, когда тесты пройдут, и смотрим результаты в workflow GitHub Actions. Но для начала заведём на Firebase проект под приложение и сгенерируем себе токен для доступа к нему из GitHub. Заходим на https://console.firebase.google.com и авторизуемся под своим Google-аккаунтом. Далее следуем по понятному визарду, нажимаем Создать проект. Указываем название Дальше отключаем Google-аналитику или оставляем всё как есть, на Test Lab это никак не повлияет. Если вам нужна аналитика, оставьте и на следующем шаге примите условия пользовательского соглашения. Когда проект создастся, приступаем к генерации токена для доступа GitHub Actions к Test Lab.  Идём в “Настройки проекта” (“Project settings”), затем на вкладку “Сервисные аккаунты” (“Service accounts”). Там выбираем “Управление правами доступа для сервисных аккаунтов” (“Manage service account permissions”). Теперь необходимо добавить сервисный аккаунт с теми правами, которые мы планируем использовать на CI/CD в GitHub Actions. Для запуска UI-тестов достаточно прав типа “Редактор”. Подробнее тут. Заполняем предлагаемые поля Выбираем тип “Редактор”. Если неправильно настроить права доступа для сервисного аккаунта, то на шаге авторизации в Firebase мы получим ошибку 403. На третьем шаге можно просто нажать кнопку “Готово” Мы только что добавили сервисный аккаунт для CI/CD и теперь готовы получить токен. Выбираем “Создать ключ” (“Create key”). Выбираем из двух предложенных вариантов JSON, после этого он автоматически скачается. Если интересно, что там внутри, - можно открыть в любом текстовом редакторе. Там записана разная служебная информация по вашему аккаунту и проекту плюс private_key. Фокус в том, что в таком виде JSON у нас не получится использовать. Придётся закодировать его через Base64. Пути два: 1) В консоли вводим Где github-actions-sample-key.json - это название скачанного на предыдущем шаге JSON, а base64-key – файл, в который будет записан результат кодирования. 2) Делаем всё на https://www.base64encode.org/ Возвращается в GitHub проект и записываем результат в Secrets в проект на GitHub. После добавления ключа в секреты обязательно удалите или перенесите в надёжное место ключ с Firebase и base64-key. Теперь необходимо добавить в секреты Project ID с экрана общих настроек проекта в Firebase. Не перепутайте с Project number. Отлично, всё готово к интеграции GitHub Actions и Test Lab. Создаём новый workflow в директории giithub/workflows. Если прямо сейчас запустить workflow, то на прогонах UI-тестов в Test Lab мы получим ошибку. Вообще-то можно пройти по ссылке из ошибки и включить API toolresults.googleapis.com, но сейчас посмотрим, как можно управлять вообще любыми API в своём проекте. Нажимаем “Enable APIs and services”.  Тут можно управлять API в проекте и смотреть статистику использования. Находим Cloud Tool Result API и включаем. Ну теперь-то уж точно всё, пора запускать workflow.  Разбираемся, что тут вообще происходит Шаг 1 Тут точно такие же установки для запуска workflow, что и раньше. Pull request в ветку main из ветки, название которой начинается на release/. Далее делаем checkout и устанавливаем окружение Java 8. Шаг 2 На этом шаге мы прогоняем unit-тесты и после собираем два APK - app-debug.apk и app-debug-androidTest.apk. Почему два? Да просто один APK - это собственно приложение для тестирования, а второй APK содержит instrumentation-тесты, они оба нам понадобятся. Дальше достаём полученные артефакты по пути и имени в upload-artifact@v2. Всё это мы уже делали раньше, когда готовили APK к релизу, так что подробно останавливаться не будем. Шаг 3 Вторая Job в тестовом workflow запускается не параллельно с первой (assemble_ui_test_artifacts), а ждёт, пока та успешно завершится. Это указано в строчке. Дальше воспользуемся готовым action download-artifact@v1 и достанем по имени те два APK которые собирали в прошлой Job. Шаг 4 Добрались до самого интересного - пора передавать артефакты в Test Lab для тестирования. Сначала выполняем action setup-gcloud, передаем в аргументах ID проекта и тот самый Base64 ключ, который хранится в секретах, всё по инструкции. Дальше просто выполняем команды в консоли. Первая gcloud firebase test android models list выведет таблицу из доступных устройств с названиями и версиями SDK. Для тестирования это не требуется, просто удобно посмотреть и выбрать подходящее устройство. Дальше запускается непосредственно тестирование, в ключах команды передаём выбранный код устройства, локаль, ориентацию экрана телефона и так далее. Полный список ключей всегда можно посмотреть в документации. Запускаем workflow и смотрим, что получилось. Отлично, всё работает, самый базовый сценарий запуска UI-тестов реализован! Подробные результаты тестирования можно посмотреть на вкладке Test Lab проекта. Или можно убрать из секретов Project ID (иначе в ссылке будут звездочки вместо ID) и переходить на результаты сразу из логов. Что ещё можно улучшить в сценарии Можно включить orchestrator, добавив ключ --use-orchestrator. Оркестратор UI-тестов будет запускать каждый тест в изолированном инстансе, что позволит избежать влияния тестов друг на друга.  --num-flaky-test-attempts - для задания количества попыток перезапуска для Flaky тестов. --network-profile - для задания профиля сети при тестировании. Можно потестировать на медленном соединении, к примеру. Полный список ключей с описанием тут: https://cloud.google.com/sdk/gcloud/reference/firebase/test/android/run Еще можно включить шардинг для запускаемых тестов  https://firebase.google.com/docs/test-lab/android/instrumentation-test#sharding https://github.com/Flank/flank Идея для самостоятельного изучения если интересно прямо сейчас что-то посмотреть: 1) Попробовать запустить UI-тесты не в Test Lab а в эмуляторе, поднимаемом на MacOS. Можно посмотреть https://github.com/ReactiveCircus/android-emulator-runner 2) Настроить матрицу тестирования для UI-тестов. Запускать тесты не на одной версии Android SDK а на каждой из заданных в условиях.  На этом с запуском UI-тестов из GitHub Actions всё :) Android developer