Configuration de test avancée

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 :

1. Dans la fenêtre Project (Projet), cliquez sur le menu, puis sélectionnez la vue Project (Projet).
2. Dans le dossier du module approprié, effectuez un clic droit sur le dossier src, puis cliquez sur New > Directory (Nouveau > Répertoire).
3. 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.
4. Cliquez sur OK.
5. Faites un clic droit sur le nouveau répertoire, puis sélectionnez New > Directory (Nouveau > Répertoire).
6. 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 :

Figure 1. La variante 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 :

Figure 2. La variante 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 :

Figure 3. La variante 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 :

Figure 4. La variante 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 :

1. Créez un module de bibliothèque.
2. Dans le fichier build.gradle au niveau du module, appliquez le plug-in com.android.test au lieu de com.android.library.
3. Cliquez sur Sync Project (Synchroniser le projet) .

Après avoir créé votre module de test, vous pouvez inclure le code de test dans l'ensemble de sources principal ou dans l'ensemble de sources des variantes (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. Grâce à la gestion des dépendances basée sur les variantes, le module de test tente de tester le type de produit correspondant 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.