Nuevo en pruebas automatizadas escalables

Publicado por Arif Sukoco, gerente de ingeniería de Android Studio (@GoogArif) Y Jolanda Verhoef, ingeniera de relaciones con desarrolladores (@Lojanda)

Sabemos que puede ser difícil ejecutar pruebas instrumentadas de Android a gran escala, especialmente cuando tiene un conjunto de pruebas grande que desea ejecutar en una variedad de perfiles de dispositivos Android.

En I / O 2021 presentamos por primera vez Plataforma de prueba unificada o UTP. UTP nos permite crear capacidades de prueba para pruebas instrumentales de Android, como ejecutar pruebas instrumentales desde Android Studio a través de Gradle y Gradle Managed Devices (GMD). GMD le permite definir un conjunto de dispositivos virtuales en build.gradley deje que Gradle los maneje ejecutándolos antes de cada ejecución de prueba instrumentada y desarmarlos después. En la última versión de Complemento de Android Gradle 7.2.0, estamos presentando más funciones más allá de GMD para ayudar a escalar las pruebas en múltiples dispositivos virtuales Android en paralelo.

Fragmentación

La primera característica que presentamos es la fragmentación sobre GMD. La fragmentación es una técnica común que se utiliza en los corredores de pruebas en la que el corredor de pruebas divide las pruebas en varios grupos o fragmentos y las ejecuta en paralelo. Con la capacidad de lanzar múltiples instancias de emulador en GMD, la fragmentación es el siguiente paso obvio para hacer de GMD una solución más escalable para grandes conjuntos de pruebas.

Cuando habilita la fragmentación para GMD y especifica la cantidad deseada de fragmentos, se iniciará automáticamente esa cantidad de dispositivos administrados por usted. Por ejemplo, el siguiente ejemplo configura un dispositivo administrado de Gradle llamado pixel2 en tus build.gradle:

android {
  testOptions {
    devices {
      pixel2 (com.android.build.api.dsl.ManagedVirtualDevice) {
        device = "Pixel 2"
        apiLevel = 30
        systemImageSource = "google"
        abi = "x86"
      }
    }
  }
}

Supongamos que tiene 4 pruebas instrumentadas en su suite de pruebas. Puede pasar una propiedad experimental a Gradle para especificar en cuántos fragmentos desea dividir sus pruebas. El siguiente comando divide la ejecución de prueba en dos fragmentos:

 ./gradlew -Pandroid.experimental.androidTest.numManagedDeviceShards=2 pixel2DebugAndroidTest

Invocar a Gradle de esta manera le dirá a GMD que inicie 2 instancias de pixel2y divida la ejecución de sus 4 pruebas instrumentadas entre estos 2 dispositivos emulados. En la salida de Gradle, verá"Starting 2 tests on pixel2_0", Y "Starting 2 tests on pixel2_1".

Como se ve en este ejemplo, la fragmentación de GMD ejecuta varios dispositivos virtuales idénticos. Si aplica fragmentación y tiene más de un dispositivo definido en build.gradle, GMD lanzará varias instancias de cada dispositivo virtual.

La salida HTML del informe de ejecución de la prueba se generará en app/build/reports/androidTests/managedDevice/pixel2. Este informe contendrá los resultados de las pruebas combinadas de todos los fragmentos.

También puede cargar los resultados de la prueba desde cualquier fragmento a Android Studio seleccionando Ejecutar> Importar prueba desde archivo desde el menú y cargando los archivos de salida de protobuf app/build/outputs/androidTest-results/managedDevice/pixel2/shard_1/test-result.pb Y app/build/outputs/androidTest-results/managedDevice/pixel2/shard_2/test-result.pb.

Vale la pena mencionar que cuando se realizan pruebas de fragmentación, siempre existe una compensación entre los recursos adicionales y el tiempo que se tarda en lanzar instancias adicionales del emulador y el ahorro en el tiempo de ejecución de la prueba. Como tal, es más útil cuando tiene que ejecutar conjuntos de pruebas más grandes.

Además, tenga en cuenta que GMD actualmente no admite pruebas para módulos de solo prueba todavía, y existen problemas de inestabilidad conocidos cuando se ejecuta en servidores de CI alojados en la nube.

Imágenes de leaner emulation system

Cuando se ejecutan varias instancias del emulador al mismo tiempo, los recursos informáticos limitados del servidor pueden convertirse en un problema.

Una de las formas de mejorar esto es reducir la imagen del sistema de emulación de Android para crear un nuevo tipo de dispositivo optimizado para ejecutar pruebas automatizadas. La imagen del sistema del dispositivo de prueba automatizada (ATD) está diseñada para consumir menos CPU y memoria al eliminar componentes que normalmente no afectan la ejecución de pruebas instrumentadas de su aplicación, como la interfaz de usuario del sistema, la aplicación de configuración, la aplicación empaquetada como Gmail, Google Maps, etc. ., y algunos otros componentes. Por favor lea el Notas de lanzamiento para obtener más información sobre la imagen del sistema ATD.

Las imágenes del sistema ATD tienen la representación por hardware deshabilitada de forma predeterminada. Esto ayuda con otra fuente común de conjuntos de pruebas de ejecución lenta. A menudo, cuando se ejecutan pruebas instrumentadas en un emulador, el acceso a la GPU del host para la aceleración del hardware de gráficos no está disponible. En este caso, el emulador elegirá usar aceleración de gráficos del software, que es mucho más intensivo en CPU. La mayoría de las funciones siguen funcionando como se esperaba con la representación por hardware desactivada, con la notable excepción de las capturas de pantalla. Si necesita tomar capturas de pantalla en su prueba, le recomendamos que consulte las nuevas API de captura de pantalla de prueba de AndroidX que habilitarán dinámicamente la representación por hardware para tomar una captura de pantalla. Por favor, eche un vistazo a ejemplos para saber cómo utilizar estas API.

Para usar ATD, primero asegúrese de haber descargado la última versión del emulador de Android del canal Canary (versión 30.9.2 o posterior). Para descargar este emulador, vaya a Apariencia y comportamiento> Configuración del sistema> Actualizaciones y establezca el menú desplegable de actualizaciones de IDE en “Canary Channel”.

A continuación, debe especificar una imagen del sistema ATD en la configuración de GMD:

android {
  testOptions {
    devices {
      pixel2 (com.android.build.api.dsl.ManagedVirtualDevice) {
        device = "Pixel 2"
        apiLevel = 30
        systemImageSource = "aosp-atd" // Or "google-atd" if you need
                                       // access to Google APIs
        abi = "x86" // Or "arm64-v8a" if you are on an Apple M1 machine
      }
    }
  }
}

Ahora puede ejecutar pruebas desde la línea de comandos de Gradle tal como lo haría con GMD como antes, incluso con la fragmentación habilitada. Lo único que necesita agregar por ahora es hacerle saber a Gradle que se está refiriendo a una imagen del sistema en el canal Canary.

./gradlew -Pandroid.sdk.channel=3
-Pandroid.experimental.androidTest.numManagedDeviceShards=2
pixel2DebugAndroidTest

La mejora del tiempo de ejecución de la prueba con ATD puede variar según la configuración de la máquina. En nuestras pruebas, comparando las imágenes del sistema ATD y no ATD que se ejecutan en una máquina Linux con una CPU Intel Xeon y 64 GB de RAM, encontramos un tiempo de ejecución de prueba un 33% más corto cuando se usa ATD, mientras que en una Macbook Pro 2020 con Intel i9 procesador y 32 GB de RAM, encontramos una mejora del 55%.

Estamos realmente entusiasmados con estas nuevas funciones y esperamos que puedan ayudarlo a escalar mejor sus pruebas instrumentadas. Por favor pruébalos y Háganos saber lo que piensas! Síganos, el equipo de desarrollo de Android Studio, en Gorjeo y ve medio.