Pruebas de instrumentación

Primero, lee Cómo probar tu app en developer.android.com. Ten en cuenta que hay algunas diferencias en el uso de las pruebas de instrumentación en las pruebas de plataforma.

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

Conceptos clave

  • Una instrumentación debe declararse en un paquete de aplicación, con una etiqueta <instrumentation> anidada en la etiqueta <manifest> del manifiesto del paquete de la aplicación.
  • Técnicamente, un manifiesto de paquete de aplicación puede contener varias etiquetas <instrumentation>, aunque no se usa de esta manera.
  • cada <instrumentation> debe contener lo siguiente:
    • Un atributo android:name: Debe ser el nombre de una subclase de Instrumentation que se incluye en la aplicación de prueba, que suele ser el ejecutor de pruebas que se usa, 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 que se está probando.

Resumen de pasos

  1. A continuación, se muestran destinos comunes para pruebas herméticas contra servicios de framework:

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

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

  2. Sigue la convención existente si agregas pruebas en una de las ubicaciones anteriores. Si estás configurando 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 la 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 de un paquete 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 de 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 si se aprueba o no con las APIs de JUnit. Además, cualquier excepción no detectada también causará una falla funcional.

Para emitir métricas de rendimiento, tu 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 los valores no numéricos.
  3. Tu APK de prueba puede ser de pruebas funcionales o de métricas, pero, por el momento, no se admite la combinación de ambas.