En utilisant des appareils gérés par Gradle, vous améliorez la cohérence, les performances et la fiabilité de vos tests d'instrumentation automatisés. Cette fonctionnalité, disponible à partir du niveau 27 de l'API, vous permet de configurer des appareils de test virtuels dans les fichiers Gradle de votre projet. Le système de compilation utilise les configurations pour gérer entièrement ces appareils lors de l'exécution des tests automatisés, c'est-à-dire pour les créer, les déployer et les supprimer.
Grâce à cette fonctionnalité, Gradle a accès aux tests que vous exécutez, mais aussi au cycle de vie des appareils, ce qui améliore la qualité de votre expérience de test, à plusieurs niveaux :
- Gradle gère les problèmes liés aux appareils pour assurer l'exécution de vos tests.
- Gradle utilise les instantanés de l'émulateur pour améliorer le temps de démarrage et l'utilisation de mémoire des appareils, et pour nettoyer les appareils entre les tests.
- Gradle met en cache les résultats des tests et ne réexécute que les tests susceptibles de donner des résultats différents.
- Gradle offre un environnement cohérent pour l'exécution de vos tests, qu'il s'agisse d'exécutions locales ou d'exécutions distantes.
De plus, les appareils gérés par Gradle introduisent un nouveau type d'appareil émulateur appelé ATD (Automated Test Device). Celui-ci est optimisé pour améliorer les performances lors de l'exécution de vos tests d'instrumentation. Vous pouvez non seulement segmenter les tests, mais aussi essayer de scinder votre suite de tests sur plusieurs instances ATD afin de réduire la durée d'exécution globale des tests.
Créer un appareil géré par Gradle
Vous pouvez spécifier un appareil virtuel que Gradle devra utiliser pour tester votre application dans votre fichier build.gradle au niveau du module. L'exemple de code suivant crée un Pixel 2 exécutant le niveau 30 de l'API sous forme d'appareil géré par 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"
}
}
}
}
}
Pour exécuter vos tests à l'aide des appareils gérés par Gradle que vous avez configurés, utilisez la commande suivante. device-name est le nom de l'appareil que vous avez configuré dans votre script de compilation Gradle (pixel2api30, par exemple) et BuildVariant est la variante de compilation de l'application à tester.
gradlew device-nameBuildVariantAndroidTest
Définir des groupes d'appareils
Pour vous aider à adapter vos tests à plusieurs configurations d'appareils, couvrant par exemple différents niveaux d'API et facteurs de forme, vous pouvez définir plusieurs appareils gérés par Gradle et les ajouter à un groupe nommé. Gradle peut ensuite exécuter vos tests sur tous les appareils du groupe en parallèle.
L'exemple ci-dessous montre deux appareils gérés ajoutés à un groupe d'appareils appelé 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"])
}
}
}
}
Pour exécuter vos tests avec le groupe d'appareils gérés par Gradle, utilisez la commande suivante :
gradlew group-nameGroupBuildVariantAndroidTest
Exécuter des tests avec des appareils de test automatisés
Les appareils gérés par Gradle disposent d'un nouveau type d'appareil émulateur appelé ATD (Automated Test Device). Celui-ci est optimisé pour réduire la consommation de ressources processeur et de mémoire lors de l'exécution de vos tests d'instrumentation. Les ATD améliorent les performances d'exécution de plusieurs manières :
- Ils suppriment les applications préinstallées qui ne sont généralement pas utiles pour tester votre application.
- Ils désactivent certains services d'arrière-plan qui ne sont généralement pas utiles pour tester votre application.
- Ils désactivent le rendu matériel.
Avant de commencer, pensez à mettre à jour Android Emulator pour disposer de la dernière version disponible. Spécifiez ensuite une image "-atd" lorsque vous définissez un appareil géré par Gradle dans le fichier build.gradle, comme indiqué ci-dessous :
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"
}
}
}
}
}
Vous pouvez également créer des groupes d'appareils, comme vous le feriez avec d'autres appareils gérés par Gradle. Pour profiter davantage des améliorations liées aux performances, vous pouvez également utiliser des ATD avec la fonctionnalité de segmentation des tests pour réduire la durée d'exécution totale de votre suite de tests.
Quels éléments sont supprimés dans les images ATD ?
En plus de fonctionner sans interface graphique, les ATD optimisent également les performances en supprimant ou en désactivant les applications et services qui ne sont généralement pas nécessaires pour tester le code de votre application. Le tableau ci-dessous présente les composants que nous avons supprimés ou désactivés dans les images ATD, ainsi qu'une description expliquant pourquoi ils ne sont pas nécessairement utiles.
| Éléments supprimés dans les images ATD | Raison pour laquelle ils ne sont pas indispensables dans le cadre des tests automatisés |
|---|---|
Applications Google :
|
Vos tests automatisés doivent se concentrer sur la logique de votre application, en supposant que les autres applications ou la plate-forme fonctionnent correctement.
Espresso-Intents vous permet d'associer et de valider vos intents sortants, et même de fournir des bouchons de réponse à la place des réponses d'intent réelles. |
Paramètres, applications et services :
|
Ces applications présentent aux utilisateurs finaux une IUG permettant de modifier les paramètres de la plate-forme, de configurer leur appareil ou d'en gérer le stockage. Ces paramètres n'entrent généralement pas dans le cadre des tests automatisés au niveau de l'application.
|
| SystemUI | Vos tests automatisés doivent se concentrer sur la logique de votre application, en supposant que les autres applications ou la plate-forme fonctionnent correctement. |
Applications et services AOSP :
|
Ces applications et services n'entrent généralement pas dans le cadre des tests automatisés du code de votre application. |
Activer la segmentation des tests
Les appareils gérés par Gradle gèrent la segmentation des tests, ce qui vous permet de scinder votre suite de tests sur plusieurs instances d'appareils virtuels identiques appelées segments, qui s'exécutent en parallèle. La segmentation des tests peut vous aider à réduire la durée d'exécution totale des tests, mais nécessite des ressources de calcul supplémentaires.
Pour définir le nombre de segments à utiliser dans une exécution de test, définissez les éléments suivants dans votre fichier gradle.properties :
android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>
Lorsque vous exécutez vos tests avec cette option, les appareils gérés par Gradle provisionnent le nombre de segments que vous spécifiez pour chaque profil d'appareil dans l'exécution du test. Par exemple, si vous avez déployé vos tests sur un groupe de trois appareils et que vous avez attribué la valeur 2 à numManagedDeviceShards, les appareils gérés par Gradle provisionneront au total six appareils virtuels pour l'exécution de votre test.
Une fois les tests terminés, Gradle écrit les résultats des tests dans un fichier .proto pour chaque segment utilisé dans l'exécution du test.