Каждый новый модуль тестирования должен иметь файл конфигурации, чтобы направлять систему сборки с метаданными модуля, зависимостями времени компиляции и инструкциями по упаковке. Теперь в Android используется система сборки Soong, которая упрощает настройку тестирования.
Soong использует файлы Blueprint или .bp, которые представляют собой простые декларативные описания модулей для сборки в формате JSON. Этот формат заменяет систему на основе Make, которая использовалась в предыдущих выпусках. Подробную информацию можно найти в справочных файлах Soong на панели управления непрерывной интеграцией.
Чтобы выполнить собственное тестирование или использовать Compatibility Test Suite (CTS) для Android, следуйте инструкциям в разделе Сложная конфигурация тестирования.
Пример
Приведенные ниже записи взяты из этого файла конфигурации Blueprint: /platform_testing/tests/example/instrumentation/Android.bp
Ниже приведен снимок экрана для удобства:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Обратите внимание на объявление android_test в начале, которое указывает на то, что это тест.
Если в имени есть android_app, это означает, что файл является пакетом сборки.
Настройки
Ниже приведены пояснения к некоторым настройкам.
name: "HelloWorldTests",
Параметр name обязателен, если указан тип модуля android_test (в начале блока). Оно присваивает название модулю, и полученный APK-файл будет называться так же, но с суффиксом .apk, например HelloWorldTests.apk. Кроме того, этот файл определяет название цели сборки для вашего модуля, чтобы вы могли использовать make [options]
<HelloWorldTests> для сборки тестового модуля и всех его зависимостей.
static_libs: ["androidx.test.runner"],
Настройка static_libs указывает системе сборки включить содержимое названных модулей в полученный APK-файл текущего модуля. Это означает, что каждый именованный модуль должен создать файл .jar, содержимое которого будет использоваться для разрешения ссылок на classpath во время компиляции, а также будет включено в полученный APK-файл.
Модуль androidx.test.runner – это предварительно созданный модуль для библиотеки AndroidX Test Runner, в которую входит средство запуска тестов AndroidJUnitRunner.
AndroidJUnitRunner поддерживает фреймворк тестирования JUnit4 и заменил InstrumentationTestRunner в Android 10. Подробнее о том, как тестировать приложения для Android…
Если вы создаете новый модуль для сбора данных, всегда начинайте с библиотеки androidx.test.runner в качестве средства запуска тестов. В дереве исходного кода платформы также есть другие полезные фреймворки для тестирования, например ub-uiautomator, mockito-target, easymock и т. д.
certificate: "platform",
Настройка certificate указывает системе сборки, что APK-файл нужно подписать тем же сертификатом, что и основную платформу. Это необходимо, если в тесте используется разрешение или API, защищенные подписью. Обратите внимание, что этот метод подходит для непрерывного тестирования платформы, но не должен использоваться в тестовых модулях CTS. Обратите внимание, что в этом примере параметр сертификата используется только для иллюстрации. Тестовому коду из примера не требуется, чтобы тестовый APK был подписан специальным сертификатом платформы.
Если вы пишете инструментарий для компонента, который находится вне системного сервера, то есть упакован примерно как обычный APK приложения, за исключением того, что он встроен в образ системы и может быть привилегированным приложением, скорее всего, ваш инструментарий будет нацелен на пакет приложения (см. раздел ниже о манифесте) вашего компонента. В этом случае в файле makefile вашего приложения может быть собственная настройка certificate, и модуль инструментации должен сохранить ту же настройку. Это связано с тем, что для тестирования приложения APK-файлы приложения и тестов должны быть подписаны одним и тем же сертификатом.
В других случаях эта настройка не нужна: система сборки просто подпишет его встроенным сертификатом по умолчанию, в зависимости от варианта сборки. Обычно он называется dev-keys.
test_suites: ["device-tests"],
Настройка test_suites позволяет легко найти тест с помощью тестового пакета Trade Federation. Сюда можно добавить другие наборы, например CTS, чтобы поделиться этим тестом.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Дополнительные настройки
Ниже приведены пояснения к необязательным настройкам.
test_config: "path/to/hello_world_test.xml"
Параметр test_config указывает системе сборки, что целевому объекту тестирования требуется определенная конфигурация. По умолчанию рядом с Android.bp находится AndroidTest.xml, связанный с конфигурацией.
auto_gen_config: true
Параметр auto_gen_config указывает, нужно ли создавать конфигурацию тестирования автоматически. Если рядом с Android.bp нет AndroidTest.xml, то этот атрибут не нужно задавать явным образом.
require_root: true
Параметр require_root указывает системе сборки добавить RootTargetPreparer
в автоматически созданную конфигурацию тестирования. Это гарантирует, что тест будет запущен с правами root.
test_min_api_level: 29
Настройка test_min_api_level указывает системе сборки добавить MinApiLevelModuleController в автоматически созданную конфигурацию тестирования. Когда Trade Federation запускает конфигурацию теста, тест пропускается, если свойство устройства ro.product.first_api_level < test_min_api_level.