Общая структура конфигурации модуля аналогична обычной XML-конфигурации Tradefed, но с некоторыми ограничениями, связанными с тем, что они работают как часть пакета.
Список разрешенных тегов
AndroidTest.xml или более широкая конфигурация модуля могут содержать только следующие теги XML: target_preparer , multi_target_preparer , test и metrics_collector .
Хотя этот список выглядит ограничивающим, он позволяет вам точно определить потребности в настройке тестового модуля и запустить тест.
ПРИМЕЧАНИЕ. См . XML-конфигурацию Tradefed, если вам нужно освежить в памяти различные теги.
Такие объекты, как build_provider или result_reporter , вызовут исключение ConfigurationException , если их попытаются запустить из конфигурации модуля. Это сделано для того, чтобы избежать ожидания того, что эти объекты фактически выполнят какую-то задачу внутри модуля.
Пример конфигурации модуля
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
Эта конфигурация описывает тест, который требует CtsGestureTestCases.apk и запускает инструментарий для пакета android.gesture.cts .
Особый случай для тега "metrics_collector"
metrics_collector разрешен, но ограничен классом FilePullerLogCollector , чтобы указать данный файл или каталог для извлечения и регистрации для модуля. Это полезно, если вы оставляете журналы в определенном месте и хотите автоматически восстановить их.
Пример конфигурации:
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.uirendering.cts" />
<option name="runtime-hint" value="11m55s" />
<option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
<option name="isolated-storage" value="false" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
Как насчет информации о сборке или загрузках?
Определение разрешенных тегов может создать неправильное впечатление, что модуль не получит никакой информации о сборке. Это неправда .
Информация о сборке предоставляется при установке на уровне пакета и будет использоваться всеми модулями пакета. Это позволяет выполнить единую настройку верхнего уровня для пакета, чтобы запускать все модули, входящие в состав пакета.
Например, вместо того, чтобы каждый модуль набора тестов совместимости (CTS) индивидуально запрашивал информацию об устройстве, типах и т. д., установка на уровне пакета CTS ( cts.xml ) делает это один раз, и каждый модуль получит эту информацию, если они ее запросят.
Чтобы объекты в модуле получали информацию о сборке, им нужно сделать то же самое, что и в обычной конфигурации Tradefed: реализовать интерфейс IBuildReceiver для получения IBuildInfo . Дополнительные сведения см. в разделе Тестирование с устройством .
Поля метаданных
Большое количество тестовых модулей включает некоторые спецификации metadata , каждая из которых имеет уникальную цель.
Пример:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
Компонент
Метаданные component описывают общий компонент Android, который модуль намеревается протестировать. Это не оказывает прямого влияния на выполнение теста; он в основном используется в организационных целях.
Актуальный список разрешенных компонентов для CTS доступен в CtsConfigLoadingTest . Этот тест не проходит предварительную отправку, если в модуль CTS добавляется несуществующий компонент.
Вы можете отфильтровать запуск пакета на основе компонентов, используя module-metadata-include-filter и module-metadata-exclude-filter .
Пример:
--module-metadata-include-filter component framework
В этом примере выполняется только тестовый модуль, аннотированный компонентом framework .
Параметр
Метаданные parameter носят информационный характер и влияют на выполнение теста. Он указывает, к какому режиму Android относится тестовый модуль. В этом случае режимы ограничены высокоуровневыми режимами Android, такими как instant apps , secondary users или different abis .
Во время выполнения пакета, если режим применяется к тесту, на основе режима создается несколько вариантов тестового модуля. Каждый вариант запускает аналогичные тесты, но в разных режимах.
-
instant_app: создайте вариант тестов, которые устанавливают APK как мгновенные приложения. -
multi_abi: создайте вариант тестов для каждого ABI, поддерживаемого устройством. -
secondary_user: создайте вариант тестов, которые устанавливают APK и запускают тесты от имени вторичного пользователя.