Les sections Tester dans Android Studio et Exécuter des tests depuis la ligne de commande expliquent comment configurer et exécuter des configurations de test de base. Toutefois, lorsqu'une application et ses exigences de test gagnent en complexité, il est parfois nécessaire d'adapter davantage les configurations de test. Par exemple, une configuration de test avancée peut être nécessaire si vous souhaitez effectuer les opérations suivantes :
- Exécuter des tests d'instrumentation uniquement pour une variante de compilation spécifique ou remplacer les paramètres de son fichier manifeste
- Modifier le type de compilation utilisé pour vos tests ou configurer ses options Gradle
- Extraire les tests d'instrumentation dans leur propre module de test
- Effectuer des tests plus avancés dans le cadre de la configuration de l'intégration continue
Cette page décrit différentes manières de configurer des tests lorsque les paramètres par défaut ne répondent pas à vos besoins.
Créer un test d'instrumentation pour une variante de compilation
Si votre projet comprend des variantes de compilation avec des ensembles de sources uniques, vous pouvez inclure des tests instrumentés qui correspondent à ces ensembles. Non seulement le code de test reste organisé, mais vous pouvez aussi exécuter uniquement les tests qui s'appliquent à une variante de compilation donnée.
Pour associer des tests d'instrumentation à une variante de compilation, placez-les dans leur propre ensemble de sources, situé dans src/androidTestVariantName
.
Les tests d'instrumentation de l'ensemble de sources src/androidTest/
sont partagés par toutes les variantes de compilation. Lorsque vous créez un APK de test pour la variante "MyFlavor" de votre application, Gradle combine les ensembles de sources src/androidTest/
et src/androidTestMyFlavor/
.
Si vous souhaitez ajouter un ensemble de sources de test pour votre variante de compilation dans Android Studio, procédez comme suit :
- Dans la fenêtre Project (Projet), cliquez sur le menu, puis sélectionnez la vue Project (Projet).
- Dans le dossier du module approprié, effectuez un clic droit sur le dossier src, puis cliquez sur New > Directory (Nouveau > Répertoire).
- Pour le nom du répertoire, saisissez "androidTestNom_de_la_variante". Par exemple, si vous disposez d'une variante de compilation appelée "MyFlavor", utilisez le nom de répertoire
androidTestMyFlavor
. - Cliquez sur OK.
- Faites un clic droit sur le nouveau répertoire, puis sélectionnez New > Directory (Nouveau > Répertoire).
- Saisissez "java" comme nom de répertoire, puis cliquez sur OK.
Pour ajouter des tests à ce nouvel ensemble de sources, suivez ces étapes. Dans la boîte de dialogue Choose Destination Directory (Sélectionner un répertoire de destination), sélectionnez le nouvel ensemble de sources de test des variantes.
Le tableau suivant illustre comment les fichiers de test d'instrumentation peuvent résider dans les ensembles de sources correspondant aux ensembles de sources du code de l'application :
Tableau 1. Code source de l'application et fichiers de test d'instrumentation correspondants
Chemin d'accès à la classe de l'application | Chemin d'accès à la classe de test d'instrumentation correspondante |
---|---|
src/main/java/Example.java
|
src/androidTest/java/AndroidExampleTest.java
|
src/myFlavor/java/Example.java
|
src/androidTestMyFlavor/java/AndroidExampleTest.java
|
Tout comme pour les ensembles de sources de votre application, le build Gradle fusionne et remplace les fichiers de différents ensembles de sources de test. Dans ce cas, le fichier AndroidExampleTest.java
de l'ensemble de sources androidTestMyFlavor
remplace la version figurant dans l'ensemble de sources androidTest
. En effet, l'ensemble de sources de types de produits a priorité sur l'ensemble de sources principal.
Lorsque vous sélectionnez différents types de produits dans le sélecteur de variantes de compilation, les dossiers androidTest
appropriés apparaissent dans la vue Android pour afficher les dossiers utilisés :
![La variante MyFlavor est sélectionnée, et le dossier androidTestMyFlavor s'affiche dans la vue Android](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-android-view.png?authuser=5&hl=fr)
MyFlavor
est sélectionnée, et le dossier androidTestMyFlavor
s'affiche dans la vue Android.Le dossier androidTestMyFlavor
ne s'affiche pas lorsqu'une autre variante est sélectionnée :
![La variante OtherFlavor est sélectionnée, et le dossier androidTestMyFlavor ne s'affiche pas dans la vue Android](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-android-view.png?authuser=5&hl=fr)
OtherFlavor
est sélectionnée, et le dossier androidTestMyFlavor
ne s'affiche pas dans la vue Android.Cette approche est légèrement différente si vous utilisez la vue Project (Projet), mais le même principe s'applique :
![La variante MyFlavor est sélectionnée, et le dossier androidTestMyFlavor est actif dans la vue "Project" (Projet)](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-project-view.png?authuser=5&hl=fr)
MyFlavor
est sélectionnée, et le dossier androidTestMyFlavor
est actif dans la vue Project (Projet).Lorsqu'une variante différente est sélectionnée, le dossier androidTestMyFlavor
est toujours visible, mais il n'apparaît pas comme actif :
![La variante OtherFlavor est sélectionnée, et le dossier androidTestMyFlavor n'est pas actif dans la vue "Project" (Projet)](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-project-view.png?authuser=5&hl=fr)
OtherFlavor
est sélectionnée, et le dossier androidTestMyFlavor
n'est pas actif dans la vue Project (Projet).Pour en savoir plus sur la fusion des ensembles de sources, consultez la section Ensembles de sources.
Configurer les paramètres du fichier manifeste d'instrumentation
Les tests d'instrumentation sont intégrés dans un APK distinct, avec leur propre fichier AndroidManifest.xml
. Lorsque Gradle crée votre APK de test, il génère automatiquement le fichier AndroidManifest.xml
et le configure avec le nœud <instrumentation>
.
L'une des raisons pour lesquelles Gradle configure ce nœud pour vous est pour s'assurer que la propriété targetPackage
spécifie le nom de package correct de l'application testée.
Pour modifier d'autres paramètres pour ce nœud, créez un autre fichier manifeste dans l'ensemble de sources de test ou configurez le fichier build.gradle
au niveau du module, comme indiqué dans l'exemple de code suivant. La liste complète des options est disponible dans la documentation de référence de l'API BaseFlavor
.
Groovy
android { ... defaultConfig { ... testApplicationId "com.example.test" testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner" testHandleProfiling true testFunctionalTest true } }
Kotlin
android { ... defaultConfig { ... testApplicationId = "com.example.test" testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner" testHandleProfiling = true testFunctionalTest = true } }
Each product flavor you configure can override properties in the
defaultConfig {}
block. To learn more, go to Configure product
flavors.
The properties in the snippet are:
Setting | Description |
---|---|
testApplicationId
|
Specifies the application ID for the test APK. |
testInstrumentationRunner
|
Specifies the fully qualified class name of the test instrumentation runner. |
testHandleProfiling
|
If set to true , enables the instrumentation class
to start and stop profiling.If set to false , profiling occurs the entire time
the instrumentation class is running. |
testFunctionalTest
|
If set to true , indicates that the Android system
should run the instrumentation class as a functional
test.The default value is false . |
Change the test build type
By default, all instrumentation tests run against the debug
build type.
You can change this to another build type by using the testBuildType
property in your module-level build.gradle
file. For example, if you want
to run your tests against your staging
build type, edit the file as
shown in the following snippet:
Groovy
android { ... testBuildType "staging" }
Kotlin
android { ... testBuildType = "staging" }
Configurer les options de test Gradle
Le plug-in Android Gradle vous permet de spécifier certaines options pour une partie ou la totalité des tests. Dans le fichier build.gradle
au niveau du module, utilisez le bloc testOptions
pour spécifier les options qui modifieront la façon dont Gradle exécute tous vos tests :
Groovy
android { ... // Encapsulates options for running tests. testOptions { reportDir "$rootDir/test-reports" resultsDir "$rootDir/test-results" } }
Kotlin
android { ... // Encapsulates options for running tests. testOptions { reportDir "$rootDir/test-reports" resultsDir = "$rootDir/test-results" } }
La propriété reportDir
modifie le répertoire dans lequel Gradle enregistre les rapports de test. Par défaut, Gradle enregistre les rapports de test dans le répertoire path_to_your_project/module_name
/build/outputs/reports/
. $rootDir
définit le chemin d'accès par rapport au répertoire racine du projet en cours.
La propriété resultsDir
modifie le répertoire dans lequel Gradle enregistre les résultats des tests. Par défaut, Gradle enregistre ces résultats dans le répertoire path_to_your_project/module_name
/build/outputs/test-results/
. $rootDir
définit le chemin d'accès par rapport au répertoire racine du projet en cours.
Si vous souhaitez spécifier des options uniquement pour les tests unitaires locaux, configurez le bloc unitTests
dans testOptions
.
Groovy
android { ... testOptions { ... // Encapsulates options for local unit tests. unitTests { returnDefaultValues true all { jvmArgs '-XX:MaxPermSize=256m' if (it.name == 'testDebugUnitTest') { systemProperty 'debug', 'true' } ... } } } }
Kotlin
android { ... testOptions { ... // Encapsulates options for local unit tests. unitTests { returnDefaultValues = true all { jvmArgs = listOf("-XX:MaxPermSize=256m") if (it.name == "testDebugUnitTest") { systemProperty = mapOf("debug" to "true") } ... } } } }
Par défaut, les tests unitaires locaux génèrent une exception chaque fois que le code que vous testez tente d'accéder aux API de la plate-forme Android, sauf si vous simulez vous-même des dépendances Android ou utilisez un framework de test comme Mockito. Toutefois, vous pouvez activer la propriété returnDefaultValues
afin que le test renvoie la valeur "null" ou "zéro" lors de l'accès aux API de la plate-forme, plutôt que de générer une exception.
Le bloc all
encapsule les options permettant de contrôler la façon dont Gradle exécute les tests unitaires locaux. Pour obtenir la liste de toutes les options que vous pouvez spécifier, consultez la documentation de référence de Gradle.
La propriété jvmArgs
définit un ou plusieurs arguments pour les JVM de test.
Vous pouvez également vérifier le nom de la tâche pour n'appliquer les options qu'aux tests que vous spécifiez. Dans l'exemple d'extrait, la propriété debug
est définie sur true
, mais uniquement pour la tâche testDebugUnitTest
.
Utiliser des modules de test distincts pour les tests d'instrumentation
Si vous souhaitez disposer d'un module dédié aux tests d'instrumentation et isoler le reste de votre code, vous pouvez créer un module de test distinct et configurer sa compilation de la même manière qu'un module de bibliothèque.
Pour créer un module de test, procédez comme suit :
- Créez un module de bibliothèque.
- Dans le fichier
build.gradle
au niveau du module, appliquez le plug-incom.android.test
au lieu decom.android.library
. - Cliquez sur Sync Project (Synchroniser le projet)
.
Après avoir créé votre module de test, vous pouvez inclure votre code de test dans l'ensemble de sources principal ou de variante (par exemple, src/main/java
ou src/variant/java
). Si votre module d'application définit plusieurs types de produit, vous pouvez les recréer dans votre module de test.
À l'aide de la gestion des dépendances basée sur les variantes, le module de test tente de tester le type de correspondance dans le module cible.
Par défaut, les modules de test ne contiennent et ne testent qu'une variante de débogage. Toutefois, vous pouvez créer des types de compilation correspondant au projet d'application testé. Pour que le module de test se concentre sur un type de compilation différent, et non sur la variante de débogage, utilisez VariantFilter
afin de désactiver la variante de débogage dans le projet de test, comme indiqué ci-dessous :
Groovy
android { variantFilter { variant -> if (variant.buildType.name.equals('debug')) { variant.setIgnore(true); } } }
Kotlin
android { variantFilter { if (buildType.name == "debug") { ignore = true } } }
Si vous souhaitez qu'un module de test ne cible que certains types de produits ou certains types de compilation d'une application, vous pouvez utiliser la propriété matchingFallbacks
pour ne cibler que les variantes souhaitées. Cela évite également au module de test d'avoir à configurer ces variantes pour lui-même.