Configuration de test avancée

Les pages Tester dans Android Studio et Tester à partir de 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

Cette page décrit différentes manières de configurer des tests lorsque les paramètres par défaut ne correspondent pas au cas d'utilisation concerné.

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 Projet à gauche, cliquez sur le menu déroulant et sélectionnez la vue Projet.
  2. Dans le dossier du module approprié, effectuez un clic droit sur le dossier src, puis cliquez sur 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", le nom du répertoire doit être "androidTestMyFlavor". Cliquez sur OK.
  4. Effectuez un clic droit sur le nouveau répertoire, puis cliquez sur Nouveau > Répertoire.
  5. 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 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/Foo.java src/androidTest/java/AndroidFooTest.java
src/myFlavor/java/Foo.java src/androidTestMyFlavor/java/AndroidFooTest.java

Tout comme pour vos ensembles de sources d'application, le build Gradle fusionne et remplace les fichiers de différents ensembles de sources de test. Dans ce cas, le fichier AndroidFooTest.java de l'ensemble de sources androidTestMyFlavor remplace la version dans l'ensemble de sources androidTest. En effet, l'ensemble de sources de types de produits a priorité sur l'ensemble de sources principal. Pour en savoir plus sur la fusion des ensembles de sources, consultez Configurer votre build.

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. Vous pouvez modifier certains des autres paramètres de ce nœud en créant un autre fichier manifeste dans l'ensemble de sources de test ou en configurant 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.

android {

    ...

    // Each product flavor you configure can override properties in the
    // defaultConfig {} block. To learn more, go to Configure product flavors.

    defaultConfig {

        ...

        // Specifies the application ID for the test APK.
        testApplicationId = "com.test.foo"

        // Specifies the fully-qualified class name of the test instrumentation
        // runner.
        testInstrumentationRunner = "android.test.InstrumentationTestRunner"

        // If set to true, enables the instrumentation class to start and stop profiling.
        // If set to false (default), profiling occurs the entire time the instrumentation
        // class is running.
        testHandleProfiling = true

        // If set to true, indicates that the Android system should run the instrumentation
        // class as a functional test. The default value is false.
        testFunctionalTest = true

    }
}

Modifier le type de compilation de test

Par défaut, tous les tests d'instrumentation s'exécutent sur le type de compilation debug. Pour modifier ce type de compilation, utilisez la propriété testBuildType dans le fichier build.gradle au niveau du module. Par exemple, si vous souhaitez exécuter vos tests sur le type de compilation staging, modifiez le fichier comme indiqué dans l'extrait suivant.

android {

    ...

    testBuildType "staging"

}

Configurer les options de test Gradle

Le plug-in Android Gradle vous permet de spécifier certaines options pour tous les tests ou seulement pour certains d'entre eux. 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 {
        // Changes the directory where Gradle saves test reports. By default,
        // Gradle saves test reports in the
        // path_to_your_project/module_name/build/outputs/reports/ directory.
        // '$rootDir' sets the path relative to the root directory of the
        // current project.
        reportDir "$rootDir/test-reports"
        // Changes the directory where Gradle saves test results. By default,
        // Gradle saves test results in the
        // path_to_your_project/module_name/build/outputs/test-results/ directory.
        // '$rootDir' sets the path relative to the root directory of the
        // current project.
        resultsDir "$rootDir/test-results"
    }
}

Kotlin

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        // Changes the directory where Gradle saves test reports. By default,
        // Gradle saves test reports in the
        // path_to_your_project/module_name/build/outputs/reports/ directory.
        // '$rootDir' sets the path relative to the root directory of the
        // current project.
        reportDir "$rootDir/test-reports"
        // Changes the directory where Gradle saves test results. By default,
        // Gradle saves test results in the
        // path_to_your_project/module_name/build/outputs/test-results/ directory.
        // '$rootDir' sets the path relative to the root directory of the
        // current project.
        resultsDir = "$rootDir/test-results"
    }
}

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 {
            // By default, local unit tests throw an exception any time the code
            // you are testing tries to access Android platform APIs (unless you
            /// mock Android dependencies yourself or with a testing framework like Mockito).
            // However, you can enable the following property so that the test
            // returns either null or zero when accessing platform APIs, rather
            // than throwing an exception.
            returnDefaultValues true

            // Encapsulates options for controlling how Gradle executes local
            // unit tests. For a list of all the options you can specify, read
            // Gradle's reference documentation.
            all {
                // Sets JVM argument(s) for the test JVM(s).
                jvmArgs '-XX:MaxPermSize=256m'

                // You can also check the task name to apply options to only the
                // tests you specify.
                if (it.name == 'testDebugUnitTest') {
                    systemProperty 'debug', 'true'
                }
                ...
            }
        }
    }
}

Kotlin

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            // By default, local unit tests throw an exception any time the code
            // you are testing tries to access Android platform APIs (unless you
            /// mock Android dependencies yourself or with a testing framework like Mockito).
            // However, you can enable the following property so that the test
            // returns either null or zero when accessing platform APIs, rather
            // than throwing an exception.
            returnDefaultValues = true

            // Encapsulates options for controlling how Gradle executes local
            // unit tests. For a list of all the options you can specify, read
            // Gradle's reference documentation.
            all {
                // Sets JVM argument(s) for the test JVM(s).
                jvmArgs = listOf("-XX:MaxPermSize=256m")

                // You can also check the task name to apply options to only the
                // tests you specify.
                if (it.name == "testDebugUnitTest") {
                    systemProperty = mapOf("debug" to "true")
                }
                ...
            }
        }
    }
}

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. Synchronisez votre projet en cliquant sur 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 en fonction des variantes, le module de test tentera pour 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 une 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.