Algunos módulos de prueba pueden requerir pasos personalizados de configuración y desmontaje que no se pueden realizar dentro del propio caso de prueba. Los ejemplos típicos pueden incluir:
- instalar otras aplicaciones (además de la aplicación de prueba)
- empujar algunos archivos al dispositivo
- ejecutar comandos (por ejemplo, adb shell pm ...)
En el pasado, los equipos de componentes generalmente recurrían a escribir una prueba del lado del host para realizar tales tareas, lo que requiere la comprensión del arnés de la Federación de comercio y, por lo general, aumenta la complejidad de un módulo de prueba.
Tomando prestado de CTS, presentamos el concepto de configuración del módulo de prueba para admitir tales tareas, la lista de tareas comunes anterior se puede lograr con solo unas pocas líneas de configuración. Para obtener la máxima flexibilidad, incluso puede implementar su propio preparador de objetivos, según lo definido por ITargetPreparer o ITargetCleaner , y configurarlos para usarlos en su propia configuración de módulo de prueba.
Una configuración de módulo de prueba para un módulo de prueba es un archivo XML obligatorio que se agrega a la carpeta de origen del módulo de nivel superior, denominado "AndroidTest.xml". El XML sigue el formato de un archivo de configuración utilizado por el arnés de automatización de pruebas de Trade Federation. Actualmente, las etiquetas principales que se manejan a través de las configuraciones del módulo de prueba son las etiquetas "target_preparer" y "test".
Preparadores de objetivos
Una etiqueta "target_preparer", como sugiere el nombre, define un preparador de destino (consulte ITargetPreparer ) que ofrece un método de configuración, que se llama antes de que se ejecute el módulo de prueba para la prueba; y si la clase a la que se hace referencia en la etiqueta “target_preparer” también implementa ITargetCleaner , su método de desmontaje se invocará después de que el módulo de prueba haya finalizado.
Para usar la configuración del módulo común incorporado, agregue un nuevo archivo 'AndroidTest.xml' en la carpeta de nivel superior para su módulo de prueba y rellénelo con el siguiente contenido:
<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>
Como ejemplo, podemos agregar las siguientes etiquetas de opción (en el comentario "insertar" arriba):
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="settings put secure accessibility_enabled 1" />
<option name="teardown-command" value="settings put secure accessibility_enabled 0" />
</target_preparer>
Las opciones configurarán el arnés de prueba para:
- antes de invocar el módulo de prueba, ejecute el comando de shell "settings put security access_enabled 1" en el dispositivo
- después de que finalice el módulo de prueba, ejecute el comando de shell "settings put security access_enabled 0"
En este ejemplo particular, la accesibilidad se habilita/deshabilita antes/después de la ejecución del módulo de prueba, respectivamente. Con un ejemplo simple demostrado, es necesario cubrir más detalles sobre cómo se usa la etiqueta "opción". Como se muestra arriba, la etiqueta puede tener dos atributos: nombre, valor. El atributo de nombre indicaba el nombre de la opción y se divide en dos partes separadas por dos puntos: el nombre abreviado del preparador y el nombre real de la opción ofrecida por el preparador.
El propósito exacto del campo de valor depende de cómo el preparador definió la opción: puede ser una cadena, un número, un valor booleano o incluso una ruta de archivo, etc. En el ejemplo anterior, el nombre "ejecutar-comando:ejecutar-comando" significa que estamos configurando el valor para la opción "ejecutar comando" definida por un preparador de objetivos con el nombre abreviado "ejecutar comando"; y el nombre "run-command:teardown-command" significa que estamos configurando el valor para la opción "teardown-command" también definida por el mismo preparador de destino con el nombre abreviado "run-command". Aquí hay un resumen de los tres preparadores de objetivos comunes:
nombre de la clase: PushFilePreparer
- nombre corto : archivo push
- función : empuja archivos arbitrarios debajo de la carpeta del caso de prueba al destino en el dispositivo
- notas :
- este preparador puede pasar de una carpeta a otra o de un archivo a otro; es decir, no puede insertar un archivo en una carpeta en el dispositivo: también debe especificar el nombre del archivo de destino en esa carpeta
- opciones :
- push-file: una especificación push, que especifica el archivo local en la ruta donde debe insertarse en el dispositivo. Puede repetirse. Si varios archivos están configurados para enviarse a la misma ruta remota, se enviará el más reciente.
- push: (en desuso) Una especificación de inserción, formateada como '
/path/to/srcfile.txt->/path/to/destfile.txt' o '/path/to/srcfile.txt->/path/to/destdir/'. Puede repetirse. Esta ruta puede ser relativa al directorio del módulo de prueba o al propio directorio de salida. - post-push: un comando para ejecutar en el dispositivo (con `
adb shell <your command>`) después de que se hayan intentado todas las inserciones. El caso de uso típico sería usar chmod para permisos
nombre de la clase: InstallApkSetup
- nombre corto: install-apk
- función: empuja archivos apk arbitrarios debajo del destino en el dispositivo
- opciones:
- test-file-name: el nombre de la aplicación que se instalará en el dispositivo.
- install-arg: Argumentos adicionales para pasar al comando pm install, incluido el guión inicial, por ejemplo, "-d". Puede repetirse
nombre de clase: RunCommandTargetPreparer
- nombre corto: comando de ejecución
- función: ejecuta comandos de shell arbitrarios antes o después de la ejecución del módulo de prueba
- opciones:
- run-command: comando de shell adb para ejecutar. Puede repetirse
- teardown-command: comando de shell adb para ejecutar durante la fase de desmontaje. Puede repetirse
clase de prueba
Una clase de prueba es la clase de Trade Federation que se utilizará para ejecutar la prueba.
<test class="com.android.tradefed.testtype.AndroidJUnitTest">
<option name="package" value="android.test.example.helloworld"/>
<option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
Aquí hay tres clases de prueba comunes:
nombre de la clase: GTest
- nombre corto: gtest
- función: una prueba que ejecuta un paquete de prueba nativo en un dispositivo dado.
- opciones:
- native-test-device-path: la ruta en el dispositivo donde se encuentran las pruebas nativas.
nombre de la clase: Prueba de instrumentación
- nombre corto: instrumentación
- función: una prueba que ejecuta un paquete de prueba de instrumentación en un dispositivo dado
- opciones:
- paquete: el nombre del paquete de manifiesto de la aplicación de prueba de Android que se va a ejecutar.
- clase: El nombre de la clase de prueba a ejecutar.
- método: El nombre del método de prueba a ejecutar.
nombre de la clase: AndroidJUnitTest
- función: una prueba que ejecuta un paquete de prueba de instrumentación en un dispositivo dado usando android.support.test.runner.AndroidJUnitRunner Esta es la forma principal de ejecutar una prueba de instrumentación.