Pruebas de instrumentación

Primero, lee Prueba tu app en developer.android.com. Ten en cuenta que existen algunas diferencias en la forma en que se usan las pruebas de instrumentación en las pruebas de la plataforma.

En resumen, una prueba de instrumentación proporciona un entorno especial de ejecución de pruebas que se inicia a través del comando am instrument, en el que se reinicia el proceso de la aplicación objetivo y se inicializa con el contexto básico de la aplicación, y se inicia un subproceso de instrumentación dentro de la VM del proceso de la aplicación. Tu código de prueba comienza la ejecución en este subproceso de instrumentación y se le proporciona una instancia de Instrumentation que brinda acceso al contexto de la aplicación y a las APIs para manipular el proceso de la aplicación en prueba.

Conceptos clave

  • Se debe declarar una instrumentación en un paquete de aplicación, con una etiqueta <instrumentation> anidada en la etiqueta <manifest> del manifiesto del paquete de aplicación.
  • Técnicamente, un manifiesto de paquete de aplicación puede contener varias etiquetas <instrumentation>, aunque no se suele usar de esta manera.
  • Cada <instrumentation> debe contener lo siguiente:
    • Un atributo android:name: Debe ser el nombre de una subclase de Instrumentation que se incluya en la aplicación de prueba, que suele ser el ejecutor de pruebas que se está usando, p.ej.: android.support.test.runner.AndroidJUnitRunner
    • Se debe definir un atributo android:targetPackage. Su valor debe establecerse en el paquete de la aplicación en prueba.

Resumen de los pasos

  1. A continuación, se indican los destinos comunes para las pruebas herméticas en los servicios del framework:

    frameworks/base/core/tests/coretests
    frameworks/base/services/tests/servicestests
    

    Si vas a agregar un módulo de instrumentación completamente nuevo para tu componente, consulta

  2. Sigue la convención existente si agregas pruebas en una de las ubicaciones anteriores. Si vas a configurar un módulo de prueba nuevo, sigue la configuración de AndroidManifest.xml y Android.mk en una de las ubicaciones anteriores.

  3. Consulta frameworks/base/core/tests/coretests/ para ver un ejemplo. Ten en cuenta que estas líneas instalan apps adicionales:

    <option name="test-file-name" value="FrameworksCoreTests.apk" />
    <option name="test-file-name" value="BstatsTestApp.apk" />
    
  4. No olvides marcar tu prueba como @SmallTest, @MediumTest o @LargeTest.

  5. Compila el módulo de prueba con m, p.ej.:

    m FrameworksCoreTests
    
  6. Ejecuta las pruebas:

    m tradefed-all
    tradefed.sh run template/local_min --template:map test=FrameworksCoreTests
    
  7. Si no usas Tradefed, instala y ejecuta las pruebas de forma manual:

    1. Instala el APK generado:
    adb install -r ${OUT}/data/app/FrameworksCoreTests/FrameworksCoreTests.apk
    
    1. Ejecuta las pruebas con varias opciones:

      1. Todas las pruebas del APK

        adb shell am instrument -w com.android.frameworks.coretests\
          /android.support.test.runner.AndroidJUnitRunner
        
      2. Todas las pruebas en un paquete de Java específico

        adb shell am instrument -w -e package android.animation \
          com.android.frameworks.coretests\
          /android.support.test.runner.AndroidJUnitRunner
        
      3. Todas las pruebas en una clase específica

        adb shell am instrument -w -e class \
          android.animation.AnimatorSetEventsTest \
          com.android.frameworks.coretests\
          /android.support.test.runner.AndroidJUnitRunner
        
      4. un método de prueba específico

        adb shell am instrument -w -e class \
          android.animation.AnimatorSetEventsTest#testCancel \
          com.android.frameworks.coretests\
          /android.support.test.runner.AndroidJUnitRunner
        

Tu prueba puede realizar una aserción explícita sobre el éxito o el error con las APIs de JUnit. Además, cualquier excepción no detectada también provocará una falla funcional.

Para emitir métricas de rendimiento, el código de prueba puede llamar a Instrumentation#sendStatus para enviar una lista de pares clave-valor. Es importante tener en cuenta lo siguiente:

  1. Las métricas pueden ser números enteros o de punto flotante.
  2. Se descartarán todos los valores no numéricos.
  3. El APK de prueba puede incluir pruebas funcionales o pruebas de métricas, pero, por el momento, no se admite la combinación de ambos tipos.