Los preparadores de destino se invocan antes de las pruebas en el nivel de prueba en el que se definen. Esto permite configurar cualquier dispositivo para que las pruebas se ejecuten sin problemas.
Interfaz base
La interfaz base es ITargetPreparer
, que permite que se ejecute la implementación de un método setUp
. Te recomendamos implementar nuestra clase abstracta básica BaseTargetPreparer
, que proporciona una función de inhabilitación integrada para inhabilitar fácilmente un preparador.
Interfaz más clara
La extensión natural de setUp
es tearDown
y la proporciona una interfaz diferente, ITargetCleaner
. Eso proporciona la interfaz tearDown
, que permite limpiar todo lo que se hizo en setUp
después de la ejecución de la prueba.
La clase BaseTargetPreparer
también extiende ITargetCleaner
.
Recomendaciones
Recomendamos que cada preparador se limite a una sola función principal, por ejemplo, instalar un APK o ejecutar un comando. Esto permite una reutilización más fácil de los preparadores.
También revisa la lista de preparadores disponibles antes de agregar uno nuevo para evitar duplicar el trabajo. Los preparadores están disponibles en tools/tradefederation/core/src/com/android/tradefed/targetprep/
.
Configuración de XML
La etiqueta del objeto es target_preparer
, por ejemplo:
<target_preparer class="com.android.tradefed.targetprep.InstallApkSetup">
<option name="install-arg" value="-d"/>
</target_preparer>
Consulta también Configura suites para obtener contexto.
Configuración de nivel superior
Si se especifica en una configuración de nivel superior, el preparador se ejecuta solo una vez para cada
dispositivo. Un ejemplo es cts-common.xml
, que es una configuración de nivel superior para las pruebas del conjunto de pruebas de compatibilidad de Android (CTS).
Configuración a nivel del módulo
Si se especifica a nivel del módulo, el preparador siempre se ejecuta antes de ese módulo. Un ejemplo es backup/AndroidTest.xml
, que define cómo Tradefed ejecuta el módulo CTS backup
.
Ten en cuenta que, si bien el preparador se ejecuta antes que el módulo, se ejecuta después de cualquier verificador de estado del sistema.