Una suite en Tradefed se refiere a una configuración en la que se ejecutan varias pruebas bajo un ejecutor de pruebas común que impulsa la ejecución general.
En Tradefed, las suites se controlan a través de la clase ITestSuite , que permite agregar y eliminar pruebas independientemente de cómo se ejecuten.
Definiciones
- Suite: Conjunto de módulos de prueba configurados para ejecutarse bajo una configuración de nivel superior similar para informar sus resultados bajo una única invocación.
- Configuración de nivel superior: configuración aplicada a los dispositivos antes de ejecutar cualquiera de los módulos de prueba.
- Configuración principal: la configuración XML Tradefed a nivel de suite que describe qué módulos deben ejecutarse y qué configuración de nivel superior debe usarse.
- Configuración a nivel de módulo: configuración aplicada a los dispositivos justo antes de ejecutar el módulo. También se conocen como configuraciones específicas del módulo .
- Configuración del módulo: se refiere a la configuración XML Tradefed
AndroidTest.xmlque describe los módulos y qué configuración a nivel de módulo se debe realizar. - Módulo: Unidad de prueba compuesta por un paso de configuración ( configuración a nivel de módulo ), un paso de ejecución de prueba y un paso de desmontaje.
- Reintento intramódulo: Reintento automático realizado por el arnés dentro del módulo.
- Reintento de la suite: repetición completa de las pruebas fallidas anteriores de la suite.
Estructura de ITestSuite
ITestSuite en Tradefed se refiere a la clase base común que impulsa la ejecución de una suite. Es compartido por todos los principales conjuntos de pruebas, específicamente Android Compatibility Test Suite (CTS) y Android Vendor Test Suite (VTS) , y garantiza una experiencia de ejecución consistente en todos los conjuntos.
A veces nos referimos a ITestSuite como el ejecutor de la suite .
El corredor de la suite sigue estos pasos al ejecutar:
- Cargue la configuración del módulo y determine qué conjunto debe ejecutarse.
Ejecute cada módulo:
- Ejecute la configuración a nivel de módulo.
- Ejecutar pruebas del módulo.
- Ejecute el desmontaje a nivel de módulo.
Informar los resultados.
Configuración de nivel superior
Desde el punto de vista de Tradefed, ITestSuite es sólo otra prueba más. Es complejo pero sigue siendo solo una prueba como cualquier otro IRemoteTest . Entonces, al especificar el ejecutor de la suite en una configuración de Tradefed, Tradefed sigue el patrón habitual de la configuración: ejecutar build_provider , target_preparer , test (nuestra suite en este caso) y target_cleaner .
Esta secuencia en la configuración de Tradefed que contiene ITestSuite es la configuración de nivel superior.
Ejemplo:
<configuration description="Common config for Compatibility suites">
<build_provider class="com.android.compatibility.common.tradefed.build.CompatibilityBuildProvider" />
<!-- Setup applied before the suite: so everything running in the suite will
have this setup beforehand -->
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="settings put global package_verifier_enable 0" />
<option name="teardown-command" value="settings put global package_verifier_enable 1"/>
</target_preparer>
<!-- Our ITestSuite implementation -->
<test class="com.android.compatibility.common.tradefed.testtype.suite.CompatibilityTestSuite" />
<result_reporter class="com.android.compatibility.common.tradefed.result.ConsoleReporter" />
</configuration>
Metadatos del módulo
Llamamos metadatos del módulo a la información adicional especificada en el módulo de prueba AndroidTest.xml . Estos metadatos le permiten especificar información adicional sobre el módulo y los módulos se pueden filtrar utilizando los metadatos.
Metadatos de ejemplo:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
Filtro de ejemplo sobre metadatos:
--module-metadata-include-filter component=framework
Lo anterior ejecutaría todos los módulos con un marco como metadatos de componentes .
Ejemplo completo AndroidTest.xml :
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<!-- Metadata -->
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<!-- End: metadata -->
<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>
Módulo parametrizado
Un tipo de metadatos especial es parameter .
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
Estos metadatos especifican que el módulo debe ejecutarse en un modo diferente, por ejemplo, como una aplicación instantánea, en lugar de un modo de aplicación estándar.
Todos los modos o parámetros posibles se describen en ModuleParameters y tienen un controlador asociado en ModuleParametersHelper que le permite cambiar la configuración del módulo para ejecutar en el modo particular.
Por ejemplo, el modo de aplicación instantánea fuerza la instalación del APK como modo instantáneo.
Para que se produzca la parametrización, la línea de comando debe habilitarla con:
--enable-parameterized-modules
También es posible ejecutar un único modo determinado con:
--enable-parameterized-modules --module-parameter <Mode>
--enable-parameterized-modules --module-parameter INSTANT_APP
Cuando se ejecuta una versión parametrizada de un módulo, informa sus resultados bajo un nombre de módulo parametrizado, por ejemplo CtsGestureTestCases[instant] versus CtsGestureTestCases base.