Каждый новый тестовый модуль должен иметь файл конфигурации для управления системой сборки с метаданными модуля, зависимостями времени компиляции и инструкциями по упаковке. Android теперь использует систему сборки Soong для более простой конфигурации теста.
Soong использует файлы Blueprint или .bp , которые являются простыми декларативными описаниями модулей для сборки в стиле JSON. Этот формат заменяет систему на основе Make, использовавшуюся в предыдущих выпусках. Подробности см. в справочных файлах Soong на панели Continuous Integration Dashboard .
Чтобы провести индивидуальное тестирование или использовать набор тестов на совместимость с Android (CTS), следуйте сложной конфигурации теста .
Пример
Записи ниже взяты из этого примера файла конфигурации 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 , например, в этом случае полученный тестовый apk будет назван HelloWorldTests.apk . Кроме того, это также определяет имя цели make для вашего модуля, так что вы можете использовать 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 читайте в разделе Тестирование приложений на Android .
Если вы создаете новый модуль инструментария, вам всегда следует начинать с библиотеки androidx.test.runner в качестве тестового раннера. Дерево исходного кода платформы также включает другие полезные тестовые фреймворки, такие как ub-uiautomator , mockito-target , easymock и другие.
certificate: "platform",
Настройка certificate предписывает системе сборки подписывать apk тем же сертификатом, что и основная платформа. Это необходимо, если ваш тест использует защищенное подписью разрешение или API. Обратите внимание, что это подходит для непрерывного тестирования платформы, но не должно использоваться в тестовых модулях CTS. Обратите внимание, что этот пример использует эту настройку сертификата только в целях иллюстрации: тестовый код примера на самом деле не требует подписи тестового apk специальным сертификатом платформы.
Если вы пишете инструментарий для своего компонента, который находится вне системного сервера, то есть он упакован более или менее как обычный apk приложения, за исключением того, что он встроен в системный образ и может быть привилегированным приложением, есть вероятность, что ваш инструментарий будет нацелен на пакет приложения (см. ниже раздел о манифесте) вашего компонента. В этом случае ваш makefile приложения может иметь собственную настройку certificate , и ваш модуль инструментирования должен сохранить ту же настройку. Это связано с тем, что для нацеливания вашего инструментирования на тестируемое приложение ваш тестовый apk и 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 сообщает системе сборки, что вашей тестовой цели нужна определенная конфигурация. По умолчанию AndroidTest.xml рядом с Android.bp связан с конфигурацией.
auto_gen_config: true
Параметр auto_gen_config указывает, следует ли автоматически создавать тестовую конфигурацию. Если AndroidTest.xml не существует рядом с Android.bp , этот атрибут не нужно явно устанавливать в значение true.
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 .