La estructura general de la configuración del módulo sigue un patrón similar a la configuración normal de Tradefed XML pero con algunas restricciones debido al hecho de que se ejecutan como parte de una suite.
Lista de etiquetas permitidas
La configuración del módulo AndroidTest.xml o más ampliamente puede contener solo las siguientes etiquetas XML: target_preparer , multi_target_preparer , test y metrics_collector .
Aunque esa lista parece restrictiva, le permite definir con precisión las necesidades de configuración del módulo de prueba y la prueba que se ejecutará.
NOTA: Consulte la configuración XML de Tradefed si necesita un repaso de las diferentes etiquetas.
Los objetos como build_provider o result_reporter generarán una ConfigurationException si se intenta ejecutar desde dentro de la configuración de un módulo. Esto está destinado a evitar la expectativa de que estos objetos realmente realicen alguna tarea desde dentro de un módulo.
Configuración de módulo de ejemplo
<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 la instalación de CtsGestureTestCases.apk y ejecutará una instrumentación contra el paquete android.gesture.cts .
Caso especial para la etiqueta "metrics_collector"
El metrics_collector está permitido, pero limitado a la clase FilePullerLogCollector para especificar un archivo o directorio determinado que se extraerá y registrará para el módulo. Esto es útil si está dejando registros en una ubicación particular y desea 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é pasa con la información de compilación o las descargas?
La definición de las etiquetas permitidas puede dar la impresión incorrecta de que un módulo no obtendrá ninguna información de compilación. Esto no es cierto .
La información de compilación se proporciona desde la configuración a nivel de suite y será compartida por todos los módulos de la suite. Esto permite una configuración única de nivel superior para la suite con el fin de ejecutar todos los módulos que forman parte de la suite.
Por ejemplo, en lugar de que cada módulo de Compatibility Test Suite (CTS) consulte individualmente la información del dispositivo, los tipos, etc., la configuración de nivel de suite CTS ( cts.xml ) lo hace una vez y cada módulo recibirá esa información si la solicita.
Para que los objetos en un módulo reciban la información de compilación, deben hacer lo mismo que en la configuración regular de Tradefed: implementar la interfaz IBuildReceiver para recibir IBuildInfo . Consulte pruebas con el dispositivo para obtener más detalles.
Campos de metadatos
Una gran cantidad de módulos de prueba incluyen algunas especificaciones de metadata , cada una de las cuales tiene 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 del component describen el componente general de Android que el módulo pretende probar. No tiene ningún impacto directo en la ejecución de la prueba; se utiliza principalmente con fines organizativos.
La lista actualizada de componentes permitidos para CTS está disponible en CtsConfigLoadingTest . Esta prueba falla en el envío previo si se agrega un componente inexistente a un módulo CTS.
Puede filtrar una ejecución de conjunto en función de los componentes mediante module-metadata-include-filter y module-metadata-exclude-filter .
Ejemplo:
--module-metadata-include-filter component framework
Este ejemplo solo ejecuta el módulo de prueba anotado con el componente del framework .
Parámetro
Los metadatos del parameter son informativos e impactan 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 modos de Android de alto nivel, como instant apps , secondary users o different abis .
Durante la ejecución de la suite, si el modo se aplica a la prueba, se crean varias variaciones del módulo de prueba en función del modo. Cada variación ejecuta pruebas similares pero bajo diferentes modos.
-
instant_app: cree una variación de las pruebas que instalan APK como aplicaciones instantáneas. -
multi_abi: cree una variación de las pruebas para cada ABI compatible con el dispositivo. -
secondary_user: crea una variación de las pruebas que instalan APK y ejecutan pruebas como un usuario secundario.