Каждый новый тестовый модуль должен иметь конфигурационный файл, который передает системе сборки метаданные модуля, зависимости времени компиляции и инструкции по упаковке. В Android теперь используется система сборки Soong для упрощения настройки тестов.
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: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Обратите внимание, что объявление android_test в начале указывает на то, что это тестовый пакет. Включение android_app наоборот, указывало бы на то, что это пакет сборки.
Настройки
Следующие настройки заслуживают пояснения:
name: "HelloWorldTests",
Параметр name необходим, если указан тип модуля android_test (в начале блока). Он задает имя вашему модулю, и результирующий APK-файл будет называться так же, но с суффиксом .apk , например, в данном случае результирующий тестовый APK-файл будет называться HelloWorldTests.apk . Кроме того, это также определяет имя цели сборки для вашего модуля, так что вы можете использовать make [options] <HelloWorldTests> для сборки вашего тестового модуля и всех его зависимостей.
static_libs: ["androidx.test.runner"],
Параметр static_libs указывает системе сборки включать содержимое указанных модулей в результирующий APK-файл текущего модуля. Это означает, что каждый указанный модуль должен создавать .jar файл, содержимое которого будет использоваться для разрешения ссылок на пути к классам во время компиляции, а также будет включено в результирующий 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 позволяет легко обнаружить тест с помощью тестовой среды Торговой федерации. Сюда можно добавить и другие наборы тестов, например, 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 запускает конфигурацию теста, тест будет пропущен, если свойство device объекта ro.product.first_api_level < test_min_api_level .