Algunos módulos de prueba pueden requerir una configuración personalizada y pasos de eliminación que no pueden que se pueda realizar dentro del caso de prueba. Entre los ejemplos típicos, se incluyen los siguientes:
- instalar otros APK (además del APK de prueba)
- enviar algunos archivos al dispositivo
- ejecutar comandos (p.ej., adb shell pm ...)
En el pasado, los equipos de componentes generalmente recurrían a escribir una prueba del lado del host para realizar estas tareas, lo que requiere comprender el aprovechamiento de la Federación de Comercio y, por lo general, aumenta la complejidad de un módulo de prueba .
Basándonos en el CTS, presentamos el concepto de configuración del módulo de prueba para admitir para realizar estas tareas, la lista de tareas comunes anterior se puede realizar con unas pocas líneas de config. Para obtener la máxima flexibilidad, incluso puedes implementar tu propia estrategia preparer, como se define en ITargetPreparer. o ITargetCleaner, y configurarlos para usarlos en la configuración de tu propio módulo de prueba.
Una configuración de módulo de prueba para un módulo de prueba es un archivo en formato XML obligatorio que se agrega a la parte superior de la carpeta de origen del módulo de nivel, denominada "AndroidTest.xml". El XML sigue el formato de un archivo de configuración que utiliza el agente de automatización de pruebas de la Federación de Comercio. Actualmente, las etiquetas principales que se controlan a través de los parámetros de configuración del módulo de prueba son “target_preparer” y “probar” rótulos nuevos rápidamente.
Preparadores de objetivos
Como su nombre lo indica, la etiqueta “target_preparer” define un preparador de destino (consulta ITargetPreparer). que ofrece un método de configuración, al que se llama antes de que se ejecute el módulo de prueba para realizar pruebas; y si la clase a la que se hace referencia en la etiqueta “target_preparer” también implements ITargetCleaner, se invocará el método de desmontaje una vez que haya finalizado el módulo de prueba.
Para usar la configuración del módulo común integrada, agrega un nuevo archivo "AndroidTest.xml" en la carpeta de nivel superior para tu módulo de prueba y completarla con la 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>
A modo de 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 agente de prueba para lo siguiente:
- antes de invocar el módulo de prueba, ejecuta el comando shell “settings put secure” Accessibility_enabled de 1" en el dispositivo
- Cuando finalice el módulo de prueba, ejecuta el comando shell “settings put secure” Accessibility_enabled de 0”
En este ejemplo en particular, la accesibilidad se habilita o inhabilita antes/después de la ejecución del módulo de prueba, respectivamente. Con un ejemplo sencillo demostrado, es necesario para explicar con más detalle cómo se usa la etiqueta "option". Como se mostró anteriormente, la etiqueta puede tener dos atributos: nombre y valor. El atributo de nombre debe hacer referencia a una de las opciones que ofrece el preparador.
El propósito exacto del campo de valor depende de cómo se definió el preparador la opción: puede ser una cadena, un número, un valor booleano o incluso una ruta de archivo. A continuación, se presenta un resumen de los tres preparadores comunes de preparación de objetivos:
nombre de clase: PushFilePreparer
- short name: push-file
- function: Envía los archivos arbitrarios de la carpeta del caso de prueba a destino en el dispositivo
- notas:
- este preparador puede enviar de carpeta a carpeta o de archivo a archivo; que es que no se puede enviar un archivo a una carpeta del dispositivo: se debe especificar también el nombre del archivo de destino en esa carpeta
- opciones:
- push-file: Una especificación push, en la que se especifica el archivo local en la ruta de acceso. donde debe enviarse en el dispositivo. Se puede repetir. Si hay varios archivos están configurados para enviarse a la misma ruta remota, el se enviará la última.
- push: (obsoleto) Una especificación push, con el formato de
"
/path/to/srcfile.txt->/path/to/destfile.txt" o "/path/to/srcfile.txt->/path/to/destdir/". Se puede repetir. Esta ruta de acceso puede estar relacionada con el directorio del módulo de prueba o con directorio en sí. - post-push: Es un comando para ejecutar en el dispositivo (con `
adb shell <your command>`) después de que se hayan intentado todos los envíos. Uso habitual caso sería usar chmod para los permisos
nombre de clase: InstallApkSetup
- short name:instalación-apk
- function: envía los archivos APK arbitrarios al destino en dispositivo
- opciones:
- test-file-name: Es el nombre del APK que se instalará. dispositivo.
- install-arg: Argumentos adicionales que se pasarán a la función pm install. con guion inicial, p.ej. “-d”. Se puede repetir
nombre de clase: RunCommandTargetPreparer
- short name: run-command
- function: Ejecuta comandos de shell arbitrarios antes o después de la prueba. ejecución del módulo
- opciones:
- run-command:Comando de shell de adb para ejecutar. Se puede repetir
- teardown-command: Es el comando adb shell que se ejecutará durante la fase de desmontaje. Se puede repetir
Clase de prueba
Una clase de prueba es la clase de la Federación de Comercio que se usa 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>
Estas son tres clases de prueba comunes:
nombre de clase: GTest
- nombre corto: gtest
- function: una prueba que ejecuta un paquete de prueba nativo en un dispositivo determinado.
- opciones:
- native-test-device-path: Es la ruta de acceso en el dispositivo en el que se encuentran las pruebas nativas.
nombre de clase: InstrumentationTest
- short name: instrumentación
- function: una prueba que ejecuta un paquete de prueba de instrumentación en un dispositivo determinado.
- opciones:
- package: Es el nombre del paquete de manifiesto de la aplicación de prueba de Android que se ejecutará.
- class: Es el nombre de la clase de prueba que se ejecutará.
- method: Es el nombre del método de prueba que se ejecutará.
nombre de clase: AndroidJUnitTest
- function: una prueba que ejecuta un paquete de prueba de instrumentación en con el comando android.support.test.runner.AndroidJUnitRunner Esta es la manera principal de ejecutar una prueba de instrumentación.