Los dispositivos administrados por Gradle mejoran la coherencia, el rendimiento y la confiabilidad de tus pruebas de instrumentación automatizadas. Esta función, disponible para el nivel de API 27 y posteriores, te permite configurar dispositivos de prueba virtuales en los archivos Gradle de tu proyecto. El sistema de compilación usa las configuraciones para administrar por completo (es decir, crear, implementar y eliminar) esos dispositivos cuando ejecutas tus pruebas automatizadas.
Esta función otorga visibilidad a Gradle no solo de las pruebas que estás ejecutando, sino también del ciclo de vida de los dispositivos, lo que mejora la calidad de tu experiencia con las pruebas de las siguientes maneras:
- Controla problemas relacionados con el dispositivo para garantizar que se ejecuten las pruebas.
- Usa instantáneas del emulador para mejorar el tiempo de inicio y el uso de memoria del dispositivo, y para restablecer los dispositivos a un estado limpio entre las pruebas.
- Almacena en caché los resultados de la prueba y vuelve a ejecutar solo las pruebas que puedan proporcionar resultados diferentes.
- Proporciona un entorno coherente para ejecutar tus pruebas entre ejecuciones locales y remotas.
Además, los dispositivos administrados por Gradle incorporan un nuevo tipo de dispositivo emulador, llamado dispositivo de prueba automatizado (ATD), que está optimizado para mejorar el rendimiento al ejecutar pruebas de instrumentación. Junto con la compatibilidad con la fragmentación de pruebas, puedes experimentar con la división de tu paquete de pruebas en varias instancias de ATD para reducir el tiempo de ejecución general.
Cómo crear un dispositivo administrado por Gradle
Puedes especificar un dispositivo virtual que quieras que Gradle use para probar tu app en el archivo build.gradle de nivel de módulo. En la siguiente muestra de código, se crea un Pixel 2 que ejecuta el nivel de API 30 como un dispositivo administrado por Gradle.
Groovy
android {
testOptions {
managedDevices {
devices {
pixel2api30 (com.android.build.api.dsl.ManagedVirtualDevice) {
// Use device profiles you typically see in Android Studio.
device = "Pixel 2"
// Use only API levels 27 and higher.
apiLevel = 30
// To include Google services, use "google".
systemImageSource = "aosp"
}
}
}
}
}
Kotlin
android {
testOptions {
managedDevices {
devices {
maybeCreate<com.android.build.api.dsl.ManagedVirtualDevice>("pixel2api30").apply {
// Use device profiles you typically see in Android Studio.
device = "Pixel 2"
// Use only API levels 27 and higher.
apiLevel = 30
// To include Google services, use "google".
systemImageSource = "aosp"
}
}
}
}
}
Para que los dispositivos administrados por Gradle que configuraste ejecuten tus pruebas, usa el siguiente comando. device-name es el nombre del dispositivo que configuraste en la secuencia de comandos de compilación de Gradle (como pixel2api30) y BuildVariant es la variante de compilación de la app que quieres probar.
gradlew device-nameBuildVariantAndroidTest
Cómo definir grupos de dispositivos
Para facilitar el ajuste de pruebas en varias configuraciones de dispositivos, como diferentes niveles de API y factores de forma, puedes definir varios dispositivos administrados por Gradle y agregarlos a un grupo con nombre. Luego, Gradle puede ejecutar tus pruebas en todos los dispositivos del grupo de manera simultánea.
En el siguiente ejemplo, se muestran dos dispositivos administrados que se agregaron a un grupo de dispositivos llamado phoneAndTablet.
Groovy
testOptions {
managedDevices {
devices {
pixel2api29 (com.android.build.api.dsl.ManagedVirtualDevice) { ... }
nexus9api30 (com.android.build.api.dsl.ManagedVirtualDevice) { ... }
}
groups {
phoneAndTablet {
targetDevices.add(devices.pixel2api29)
targetDevices.add(devices.nexus9api30)
}
}
}
}
Kotlin
testOptions {
managedDevices {
devices {
maybeCreate<com.android.build.api.dsl.ManagedVirtualDevice>("pixel2api29").apply { ... }
maybeCreate<com.android.build.api.dsl.ManagedVirtualDevice>("nexus9api30").apply { ... }
}
groups {
maybeCreate("phoneAndTablet").apply {
targetDevices.add(devices["pixel2api29"])
targetDevices.add(devices["nexus9api30"])
}
}
}
}
Para ejecutar las pruebas utilizando el grupo de dispositivos administrados por Gradle, usa el siguiente comando:
gradlew group-nameGroupBuildVariantAndroidTest
Cómo ejecutar pruebas con dispositivos de prueba automatizados
Los dispositivos administrados por Gradle admiten un nuevo tipo de dispositivo emulador, llamado dispositivo de prueba automatizado (ATD), que está optimizado para reducir los recursos de CPU y memoria al ejecutar pruebas de instrumentación. Los ATD mejoran el rendimiento del tiempo de ejecución de las siguientes maneras:
- Quitan las apps preinstaladas que comúnmente no resultan útiles para probar tu app.
- Inhabilitan ciertos servicios en segundo plano que comúnmente no son útiles para probar tu app.
- Inhabilitan la renderización del hardware.
Antes de comenzar, no olvides actualizar Android Emulator a la versión más reciente disponible. Luego, especifica una imagen "-atd" al definir un dispositivo administrado por Gradle en build.gradle, como se muestra a continuación:
Groovy
android {
testOptions {
managedDevices {
devices {
pixel2api30 (com.android.build.api.dsl.ManagedVirtualDevice) {
// Use device profiles you typically see in Android Studio.
device = "Pixel 2"
// ATDs currently support only API level 30.
apiLevel = 30
// You can also specify "google-atd" if you require Google Play Services.
systemImageSource = "aosp-atd"
}
}
}
}
}
Kotlin
android {
testOptions {
managedDevices {
devices {
maybeCreate<com.android.build.api.dsl.ManagedVirtualDevice>("pixel2api30").apply {
// Use device profiles you typically see in Android Studio.
device = "Pixel 2"
// ATDs currently support only API level 30.
apiLevel = 30
// You can also specify "google-atd" if you require Google Play Services.
systemImageSource = "aosp-atd"
}
}
}
}
}
También puedes crear grupos de dispositivos como lo haces con otros dispositivos administrados por Gradle. Para aprovechar todavía más las mejoras de rendimiento, también puedes usar ATD con fragmentación de pruebas a fin de reducir el tiempo total de ejecución de la prueba.
¿Qué se quita de las imágenes de ATD?
Además de operar en un modo sin interfaz gráfica, los ATDs también optimizan el rendimiento al inhabilitar o eliminar las apps y los servicios que, por lo general, no son necesarios para probar el código de tu app. En la siguiente tabla, se proporciona una descripción general de los componentes que quitamos o inhabilitamos en las imágenes de ATD y las descripciones de los motivos por los que podrían no ser útiles.
| Qué se quita de las imágenes de ATD | Por qué es posible que no lo necesites al ejecutar pruebas automatizadas |
|---|---|
Apps de productos de Google:
|
Tus pruebas automatizadas deben enfocarse en la lógica de tu propia app y suponer que otras apps o la plataforma funcionarán correctamente.
Con Espresso-Intents, puedes hacer coincidir y validar los intents salientes o incluso proporcionar respuestas de stub en lugar de respuestas de intents reales. |
Configuración de apps y servicios:
|
Estas apps presentan una GUI para que los usuarios finales puedan cambiar la configuración de la plataforma, realizar ajustes en su dispositivo o administrar su almacenamiento. Esto suele estar fuera del alcance de las pruebas automatizadas a nivel de la app.
|
| IU del sistema | Tus pruebas automatizadas deben enfocarse en la lógica de tu propia app y suponer que otras apps o la plataforma funcionarán correctamente. |
Apps y servicios del AOSP:
|
Estas apps y servicios suelen estar fuera del alcance de las pruebas automatizadas del código de tu app. |
Cómo habilitar la fragmentación de pruebas
Los dispositivos administrados por Gradle admiten la fragmentación de pruebas, que te permite dividir tu paquete de pruebas en una serie de instancias de dispositivos virtuales idénticas llamadas fragmentos, que se ejecutan en simultáneo. El uso de la fragmentación de pruebas puede ser útil para reducir el tiempo general de ejecución de pruebas a costa de recursos de procesamiento adicionales.
Para establecer la cantidad de fragmentos que quieres usar en la ejecución de una prueba determinada, configura lo siguiente en tu archivo gradle.properties:
android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>
Cuando ejecutas tus pruebas con esta opción, los dispositivos administrados por Gradle aprovisionan la cantidad de fragmentos que especificas para cada perfil de dispositivo en la ejecución de la prueba. Por ejemplo, si implementaste las pruebas en un grupo de tres dispositivos y configuraste numManagedDeviceShards en dos, los dispositivos administrados por Gradle aprovisionarán un total de seis dispositivos virtuales para la ejecución de la prueba.
Cuando se completan tus pruebas, Gradle genera los resultados de la prueba en un archivo .proto para cada fragmento que se usa en la ejecución de la prueba.