Configuración de pruebas complejas

Es posible que algunos módulos de prueba requieran pasos de configuración y desinstalación personalizados que no se puedan realizar dentro del caso de prueba. Entre los ejemplos típicos, se incluyen los siguientes:

  • instalar otros APKs (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 solían recurrir a escribir una prueba del host para realizar esas tareas, lo que requiere comprender el arnés de Trade Federation y, por lo general, aumenta la complejidad de un módulo de prueba .

Tomando como base el CTS, presentamos el concepto de configuración del módulo de prueba para admitir esas 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 puedes implementar tu propio preparador de destino, como se define en ITargetPreparer o ITargetCleaner, y configurarlos para que se usen en tu propia configuración del módulo de prueba.

Una configuración del módulo de prueba para un módulo de prueba es un archivo en formato XML obligatorio que se agrega a la carpeta de origen del módulo de nivel superior, denominada “AndroidTest.xml”. El XML sigue el formato de un archivo de configuración que usa 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 destino

Una etiqueta “target_preparer”, como su nombre lo indica, 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. Si la clase a la que se hace referencia en la etiqueta “target_preparer” también implementa ITargetCleaner, se invocará su método de desinstalación después de que finalice el módulo de prueba.

Para usar la configuración del módulo común integrada, agrega un archivo nuevo “AndroidTest.xml” en la carpeta de nivel superior de tu módulo de prueba y complétalo 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 “insert” anterior):

    <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 lo siguiente:

  1. Antes de que se invoque el módulo de prueba, ejecuta el comando shell “settings put secure accessibility_enabled 1” en el dispositivo.
  2. Después de que finalice el módulo de prueba, ejecuta el comando shell “settings put secure accessibility_enabled 0”.

En este ejemplo en particular, la accesibilidad se habilita o inhabilita antes o 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 “option”. Como se muestra arriba, la etiqueta puede tener dos atributos: name y value. El atributo name debe hacer referencia a una de las opciones que ofrece el preparador.

El propósito exacto del campo value 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 acceso a un archivo. A continuación, se muestra un resumen de los tres preparadores de destino comunes:

  • Nombre de la clase: PushFilePreparer

    • Nombre corto: push-file
    • Función: Envía archivos arbitrarios en la carpeta de casos de prueba al destino en el dispositivo.
    • Notas:
      • Este preparador puede enviar archivos de carpeta a carpeta o de archivo a archivo. Es decir, no puedes enviar un archivo en una carpeta en el dispositivo: también debes especificar el nombre de archivo de destino en esa carpeta.
    • Opciones:
      • push-file: Una especificación de envío que especifica el archivo local a la ruta de acceso en la que se debe enviar en el dispositivo. Se puede repetir. Si se configuran varios archivos para que se envíen a la misma ruta de acceso remota, se enviará el más reciente.
      • push: (obsoleto) Una especificación de envío, con el formato '/path/to/srcfile.txt->/path/to/destfile.txt' o '/path/to/srcfile.txt->/path/to/destdir/'. Se puede repetir. Esta ruta de acceso puede ser relativa al directorio del módulo de prueba o al directorio de salida.
      • post-push: Un comando para ejecutar en el dispositivo (con `adb shell <your command>`) después de que se hayan intentado todos los envíos. Un caso de uso típico sería usar chmod para los permisos.
  • Nombre de la clase: InstallApkSetup

    • Nombre corto:install-apk
    • Función: Envía archivos APK arbitrarios en al destino en el dispositivo.
    • Opciones:
      • test-file-name: El nombre del APK que se instalará en el dispositivo.
      • install-arg: Argumentos adicionales que se pasarán al comando pm install, incluido el guion inicial, p.ej., “-d”. Se puede repetir.
  • Nombre de la clase: RunCommandTargetPreparer

    • Nombre corto: run-command
    • Función: Ejecuta comandos shell arbitrarios antes o después de la ejecución del módulo de prueba.
    • Opciones:
      • run-command: Comando shell de adb para ejecutar. Se puede repetir.
      • teardown-command: Comando shell de adb para ejecutar durante la fase de desinstalación. Se puede repetir.

Clase de prueba

Una clase de prueba es la clase de Trade Federation 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 la clase: GTest

    • Nombre corto: gtest
    • Función: Una prueba que ejecuta un paquete de prueba nativo en un dispositivo determinado.
    • Opciones:
      • native-test-device-path:La ruta de acceso en el dispositivo donde se encuentran las pruebas nativas.
  • Nombre de la clase: InstrumentationTest

    • Nombre corto: instrumentation
    • Función: Una prueba que ejecuta un paquete de prueba de instrumentación en un dispositivo determinado.
    • Opciones:
      • package: El nombre del paquete de manifiesto de la aplicación de prueba de Android que se ejecutará.
      • class:El nombre de la clase de prueba que se ejecutará.
      • method:El nombre del método de prueba que se ejecutará.
  • Nombre de la clase: AndroidJUnitTest

    • Función: Una prueba que ejecuta un paquete de prueba de instrumentación en un dispositivo determinado con android.support.test.runner.AndroidJUnitRunner. Esta es la forma principal de ejecutar una prueba de instrumentación.