Каждый новый тестовый модуль должен иметь файл конфигурации для управления системой сборки с метаданными модуля, зависимостями времени компиляции и инструкциями по упаковке. Android теперь использует систему сборки Soong для более простой настройки тестов.
Сун использует файлы Blueprint или .bp , которые представляют собой простые декларативные описания модулей для сборки в формате JSON. Этот формат заменяет систему на основе Make, использовавшуюся в предыдущих выпусках. Полную информацию см. в справочных файлах Soong на панели мониторинга непрерывной интеграции .
Чтобы провести индивидуальное тестирование или использовать набор тестов на совместимость с Android (CTS), вместо этого используйте сложную тестовую конфигурацию .
Пример
Записи ниже взяты из этого примера файла конфигурации Blueprint: /platform_testing/tests/example/instrumentation/Android.bp
Снимок включен здесь для удобства:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["android-support-test"],
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: ["android-support-test"],
Параметр static_libs указывает системе сборки включить содержимое именованных модулей в результирующий apk текущего модуля. Это означает, что ожидается, что каждый именованный модуль создаст файл .jar , а его содержимое будет использоваться для разрешения ссылок на пути к классам во время компиляции, а также будет включено в результирующий apk.
В этом примере вещи, которые могут быть полезны для тестов:
android-support-test — это предварительно созданная библиотека поддержки тестирования Android, в которую входит новый инструмент запуска тестов AndroidJUnitRunner : замена устаревшего встроенного InstrumentationTestRunner с поддержкой среды тестирования JUnit4. Подробнее читайте в разделе Тестирование приложений на Android .
Если вы создаете новый инструментальный модуль, вы всегда должны начинать с библиотеки android-support-test в качестве средства запуска тестов. Дерево исходного кода платформы также включает другие полезные среды тестирования, такие как ub-uiautomator , mockito-target , easymock и другие.
certificate: "platform",
Параметр certificate указывает системе сборки подписывать apk тем же сертификатом, что и основная платформа. Это необходимо, если в вашем тесте используется защищенное подписью разрешение или API. Обратите внимание, что это подходит для непрерывного тестирования платформы, но не должно использоваться в тестовых модулях CTS. Обратите внимание, что в этом примере этот параметр сертификата используется только в целях иллюстрации: тестовый код примера на самом деле не требует, чтобы тестовый apk был подписан специальным сертификатом платформы.
Если вы пишете инструментарий для своего компонента, который находится за пределами системного сервера, то есть он упакован более или менее как обычный APK-файл приложения, за исключением того, что он встроен в образ системы и может быть привилегированным приложением, есть вероятность, что ваш инструментарий будет ориентироваться на пакет приложения (см. ниже раздел о манифесте) вашего компонента. В этом случае make-файл вашего приложения может иметь собственную настройку certificate , и ваш инструментальный модуль должен сохранить ту же настройку. Это связано с тем, что для таргетинга инструментария на тестируемое приложение ваш тестовый APK и APK приложения должны быть подписаны одним и тем же сертификатом.
В других случаях вам вообще не нужно иметь этот параметр: система сборки просто подпишет его с помощью встроенного сертификата по умолчанию на основе варианта сборки, и он обычно называется dev-keys .
test_suites: ["device-tests"],
Параметр test_suites делает тест легко обнаруживаемым тестовой программой Торговой федерации. Сюда можно добавить другие наборы, такие как 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 в автоматически сгенерированную тестовую конфигурацию. Это гарантирует запуск теста с правами суперпользователя.
test_min_api_level: 29
Параметр test_min_api_level указывает системе сборки добавить MinApiLevelModuleController в автоматически сгенерированную тестовую конфигурацию. Когда Trade Federation запускает тестовую конфигурацию, тест будет пропущен, если свойство устройства ro.product.first_api_level < test_min_api_level .