La estructura general de la configuración del módulo sigue un patrón similar al de la configuración XML normal de Tradefed, pero con algunas restricciones debido a que se ejecutan como parte de un conjunto de pruebas.
Lista de etiquetas permitidas
AndroidTest.xml o, de manera más general, la configuración del módulo solo puede contener las siguientes etiquetas XML: target_preparer, multi_target_preparer, test y metrics_collector.
Si bien esa lista parece restrictiva, te permite definir con precisión las necesidades de configuración del módulo de prueba y la prueba que se ejecutará.
NOTA: Consulta la configuración de XML de Tradefed si necesitas un repaso sobre las diferentes etiquetas.
Los objetos como build_provider o result_reporter generarán un ConfigurationException si se intenta ejecutarlos desde la configuración de un módulo. Esto tiene como objetivo evitar la expectativa de que estos objetos realmente realicen alguna tarea desde un módulo.
Ejemplo de configuración del módulo
<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>
Esta configuración describe una prueba que requiere que se instale CtsGestureTestCases.apk y ejecutará una instrumentación en el paquete android.gesture.cts.
Etiquetas de inclusión <include> y <template-include>
Se desaconseja el uso de <include> y <template-include> en los parámetros de configuración del módulo. No se garantiza que funcionen como se espera.
Caso especial para la etiqueta metrics_collector
Se permite el uso de metrics_collector, pero se limita a la clase FilePullerLogCollector para especificar un archivo o directorio determinado que se extraerá y registrará para el módulo. Esto es útil si dejas registros en una ubicación específica y quieres recuperarlos automáticamente.
Ejemplo de configuración:
<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>
¿Qué sucede con la información de compilación o las descargas?
La definición de las etiquetas permitidas podría dar la impresión incorrecta de que un módulo no recibirá información de compilación. Eso no es cierto.
La información de compilación se proporciona desde la configuración a nivel del conjunto de pruebas y la compartirán todos los módulos del conjunto de pruebas. Esto permite una sola configuración de nivel superior para el paquete, de modo que se ejecuten todos los módulos que forman parte de él.
Por ejemplo, en lugar de que cada módulo del Conjunto de pruebas de compatibilidad (CTS) consulte individualmente la información, los tipos, etcétera del dispositivo, la configuración a nivel del conjunto de pruebas del CTS (cts.xml) lo hace una vez, y cada módulo recibirá esa información si la solicita.
Para que los objetos de un módulo reciban la información de compilación, deben hacer lo mismo que en la configuración normal de Tradefed: implementar la interfaz IBuildReceiver para recibir el IBuildInfo. Consulta Cómo realizar pruebas con un dispositivo para obtener más detalles.
Campos de metadatos
Una gran cantidad de módulos de prueba incluyen algunas especificaciones de metadata, cada una con un objetivo único.
Ejemplo:
<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" />
Componente
Los metadatos de component describen el componente general de Android que el módulo pretende probar. No tiene un impacto directo en la ejecución de la prueba, sino que se usa principalmente con fines organizativos.
La lista actualizada de componentes permitidos para CTS está disponible en CtsConfigLoadingTest. Esta prueba falla en la verificación previa a la confirmación si se agrega un componente no existente a un módulo del CTS.
Puedes filtrar la ejecución de un conjunto de pruebas según los componentes con module-metadata-include-filter y module-metadata-exclude-filter.
Ejemplo:
--module-metadata-include-filter component framework
En este ejemplo, solo se ejecuta el módulo de prueba anotado con el componente framework.
Parámetro
Los metadatos parameter son informativos y afectan la ejecución de la prueba. Especifica a qué modo de Android se aplica el módulo de prueba.
En este caso, los modos se limitan a los modos de Android de alto nivel, como instant apps, secondary users o different abis.
Durante la ejecución del conjunto, si el modo se aplica a la prueba, se crean varias variaciones del módulo de prueba según el modo. Cada variación ejecuta pruebas similares, pero en diferentes modos.
instant_app: Crea una variación de las pruebas que instalan APKs como apps instantáneas.multi_abi: Crea una variación de las pruebas para cada ABI compatible con el dispositivo.secondary_user: Crea una variación de las pruebas que instalan APKs y ejecutan pruebas como usuario secundario.
Recopilación de métricas y posprocesamiento para módulos de pruebas de rendimiento
En el caso de los módulos de prueba de rendimiento, se permiten metrics_collector y metric_post_processor a nivel del módulo, ya que son esenciales para las pruebas de rendimiento.
Los recopiladores de métricas y los posprocesadores a nivel del módulo pueden ser específicos del módulo.
No se recomienda especificar posprocesadores a nivel superior y a nivel del módulo.
La configuración de un módulo de prueba de rendimiento debe incluir los metadatos test-type con el valor performance, como se muestra a continuación:
xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />
Sin esto, si una configuración de prueba incluye metric_collector que no sea FilePullerLogCollector o cualquier metric_post_processor, la prueba fallará en la etapa previa a la confirmación.
Ejemplo de configuración del módulo de prueba de rendimiento:
<configuration description="Runs sample performance test.">
<!-- Declare as a performance test module -->
<option name="config-descriptor:metadata" key="test-type" value="performance" />
<option name="test-tag" value="hello-world-performance-test" />
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
</test>
<!-- Add module-level post processor MetricFilePostProcessor -->
<metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
<option name="aggregate-similar-tests" value="true" />
<option name="enable-per-test-log" value="false" />
</metric_post_processor>
</configuration>