Google github android test

Прокачиваем Android проект с GitHub Actions. Часть 2

Запуск UI-тестов на GitHub Actions

Продолжаем разбираться с автоматизацией 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 – файл, в который будет записан результат кодирования.

Возвращается в 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 — для задания профиля сети при тестировании. Можно потестировать на медленном соединении, к примеру.

Полный список ключей с описанием тут:

Еще можно включить шардинг для запускаемых тестов

Идея для самостоятельного изучения если интересно прямо сейчас что-то посмотреть:

1) Попробовать запустить UI-тесты не в Test Lab а в эмуляторе, поднимаемом на MacOS. Можно посмотреть https://github.com/ReactiveCircus/android-emulator-runner

2) Настроить матрицу тестирования для UI-тестов. Запускать тесты не на одной версии Android SDK а на каждой из заданных в условиях.

На этом с запуском UI-тестов из GitHub Actions всё 🙂

Источник

Google github android test

Test Device Policy Control (Test DPC) App

Test DPC is an app designed to help EMMs, ISVs, and OEMs to test their applications and platforms in a Android enterprise managed profile (i.e. work profile). It serves as both a sample Device Policy Controller and a testing application to flex the APIs available for Android enterprise. It supports devices running Android 5.0 Lollipop or later.

See the documentation to learn more about Android in the enterprise.

This sample uses the Gradle build system. To build this project, use the «gradlew assemble» command or use «Import Project» in Android Studio.

This app can also be found on the Play store.

You can find various kinds of provisioning methods here. Let’s take a few of them as an example.

QR code provisioing (Device Owner N+ only)

1. Factory reset your device and tap the welcome screen in setup wizard 6 times.
2. The setup wizard prompts the user to connect to the Internet so the setup wizard can download a QR code reader.
3. Modify (if needed) and scan [this QR code] (http://down-box.appspot.com/qr/nQB0tw7b).
4. Follow onscreen instructions

NFC provisioning (Device Owner)

The NFC Provisioning app is used for device owner provisioning.

1. Push the nfcprovisioning.txt file to your device: adb push nfcprovisioning.txt /sdcard/
2. Open the NFC Provisioning app and ensure that com.afwsamples.testdpc is auto-populated.
3. Bump the devices and touch to beam.
4. Follow onscreen instructions on the target device.

adb command (Device Owner)

adb shell dpm set-device-owner com.afwsamples.testdpc/.DeviceAdminReceiver

The easiest way is to launch the Test DPC app in launcher and follow the onscreen instructions.

If you’ve found an error in this sample, please file an issue: https://github.com/googlesamples/android-testdpc/issues

Patches are encouraged, and may be submitted by forking this project and submitting a pull request through GitHub.

Licensed under the Apache 2.0 license. See the LICENSE file for details.

How to make contributions?

Please read and follow the steps in the CONTRIB file.

About

Test DPC is a sample device policy controller for use with Android Enterprise. It gives developers the ability to see how their app will behave in a managed context such as device owner or within a managed profile. Users can set up a work profile, enable work apps, set applications restrictions, manage security polices, and much more. The app al…

Источник

Google github android test

Android testing samples

A collection of samples demonstrating different frameworks and techniques for automated testing.

BasicSample — Basic Espresso sample

CustomMatcherSample — Shows how to extend Espresso to match the hint property of an EditText

DataAdapterSample — Showcases the onData() entry point for Espresso, for lists and AdapterViews

FragmentScenarioSample — Basic usage of FragmentScenario with Espresso.

IdlingResourceSample — Synchronization with background jobs

IntentsBasicSample — Basic usage of intended() and intending()

IntentsAdvancedSample — Simulates a user fetching a bitmap using the camera

MultiWindowSample — Shows how to point Espresso to different windows

RecyclerViewSample — RecyclerView actions for Espresso

ScreenshotSample — Screenshot capturing and saving using Espresso and androidx.test.core APIs

WebBasicSample — Use Espresso-web to interact with WebViews

BasicSampleBundled — Basic sample for Eclipse and other IDEs

MultiProcessSample — Showcases how to use multiprocess Espresso.

BasicSample — Basic UI Automator sample

AndroidJunitRunnerSample — Showcases test annotations, parameterized tests and testsuite creation

JUnit4 Rules Sample

**All previous samples use ActivityTestRule or IntentsTestRule but there’s one specific to ServiceTestRule:

BasicSample — Simple usage of ActivityTestRule

IntentsBasicSample — Simple usage of IntentsTestRule

ServiceTestRuleSample — Simple usage of ServiceTestRule

• Android SDK v28
• Android Build Tools v28.03

These samples use the Gradle build system. To build a project, enter the project directory and use the ./gradlew assemble command or use «Import Project» in Android Studio.

• Use ./gradlew connectedAndroidTest to run the tests on a connected emulator or device.
• Use ./gradlew test to run the unit test on your local host.

There is a top-level build.gradle file if you want to build and test all samples from the root directory. This is mostly helpful to build on a CI (Continuous Integration) server.

AndroidX Test Library

Many of these samples use the AndroidX Test Library. Visit the Testing site on developer.android.com for more information.

Experimental Bazel Support

Some of these samples can be tested with Bazel on Linux. These samples contain a BUILD.bazel file, which is similar to a build.gradle file. The external dependencies are defined in the top level WORKSPACE file.

This is experimental feature. To run the tests, please install the latest version of Bazel (0.12.0 or later) by following the instructions on the Bazel website.

For more information, check out the documentation for Android Instrumentation Tests in Bazel. You may also want to check out Building an Android App with Bazel, and the list of Android Rules in the Bazel Build Encyclopedia.

• Building of APKs is supported on Linux, Mac and Windows, but testing is only supported on Linux.
• android_instrumentation_test.target_device attribute still needs to be specified even if —config=local_device is used.
• If using a local device or emulator, the APKs are not uninstalled automatically after the test. Use this command to remove the packages:
  • adb shell pm list packages com.example.android.testing | cut -d ‘:’ -f 2 | tr -d ‘\r’ | xargs -L1 -t adb uninstall

Please file Bazel related issues against the Bazel repository instead of this repository.

• Google+ Community: https://plus.google.com/communities/105153134372062985968
• Stack Overflow: http://stackoverflow.com/questions/tagged/android-testing

If you’ve found an error in this sample, please file an issue: https://github.com/googlesamples/android-testing

Patches are encouraged, and may be submitted by forking this project and submitting a pull request through GitHub. Please see CONTRIBUTING.md for more details.

Copyright 2015 The Android Open Source Project, Inc.

Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the «License»); you may not use this file except in compliance with the License. You may obtain a copy of the License at

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an «AS IS» BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

About

A collection of samples demonstrating different frameworks and techniques for automated testing

Источник