Schémas courants

Vous pouvez tester votre application Compose à l'aide d'approches et de modèles bien établis.

Effectuer un test isolé

ComposeTestRule vous permet de lancer une activité affichant n'importe quel composable : votre application complète, un seul écran ou un petit élément. Il est également recommandé de vérifier que vos composables sont correctement encapsulés et fonctionnent de manière autonome afin de tester l'interface utilisateur plus facilement et plus précisément.

Cela ne signifie pas que vous devez uniquement créer des tests d'interface utilisateur. Il est également très important de tester la portée de plus grandes parties de votre interface utilisateur.

Accédez à l'activité et aux ressources après avoir défini votre propre contenu

Vous devez souvent définir le contenu testé à l'aide de composeTestRule.setContent et accéder aux ressources d'activité, par exemple pour déclarer qu'un texte affiché correspond à une ressource de chaîne. Toutefois, vous ne pouvez pas appeler setContent sur une règle créée avec createAndroidComposeRule() si l'activité l'appelle déjà.

Pour ce faire, il est courant de créer une AndroidComposeTestRule à l'aide d'une activité vide comme ComponentActivity.

class MyComposeTest {

    @get:Rule
    val composeTestRule = createAndroidComposeRule<ComponentActivity>()

    @Test
    fun myTest() {
        // Start the app
        composeTestRule.setContent {
            MyAppTheme {
                MainScreen(uiState = exampleUiState, /*...*/)
            }
        }
        val continueLabel = composeTestRule.activity.getString(R.string.next)
        composeTestRule.onNodeWithText(continueLabel).performClick()
    }
}

Notez que ComponentActivity doit être ajouté au fichier AndroidManifest.xml de votre application. Pour ce faire, ajoutez cette dépendance à votre module:

debugImplementation("androidx.compose.ui:ui-test-manifest:$compose_version")

Propriétés de la sémantique personnalisée

Vous pouvez créer des propriétés sémantiques personnalisées pour présenter des informations aux tests. Pour ce faire, définissez une nouvelle SemanticsPropertyKey et rendez-la disponible à l'aide de SemanticsPropertyReceiver.

// Creates a semantics property of type Long.
val PickedDateKey = SemanticsPropertyKey<Long>("PickedDate")
var SemanticsPropertyReceiver.pickedDate by PickedDateKey

Utilisez maintenant cette propriété dans le modificateur semantics:

val datePickerValue by remember { mutableStateOf(0L) }
MyCustomDatePicker(
    modifier = Modifier.semantics { pickedDate = datePickerValue }
)

À partir des tests, utilisez SemanticsMatcher.expectValue pour réclamer la valeur de la propriété:

composeTestRule
    .onNode(SemanticsMatcher.expectValue(PickedDateKey, 1445378400)) // 2015-10-21
    .assertExists()

Avertissement :Vous ne devez utiliser des propriétés sémantiques personnalisées que lorsqu'il est difficile de faire correspondre un élément spécifique avec les outils de recherche et de mise en correspondance fournis. Il n'est pas recommandé d'utiliser des propriétés sémantiques personnalisées pour révéler des propriétés visuelles comme les couleurs, la taille de la police ou l'arrondi des coins des encadrés, car cela peut polluer le code de production, et des mises en œuvre incorrectes peuvent provoquer des bugs difficiles à trouver.

Vérifier la restauration d'état

Vérifiez que l'état de vos éléments Compose est correctement restauré lorsque l'activité ou le processus est recréé. Effectuez ces vérifications sans dépendre de la recréation d'activité avec la classe StateRestorationTester.

Cette classe vous permet de simuler la recréation d'un composable. Elle s'avère particulièrement utile pour vérifier la mise en œuvre de rememberSaveable.

class MyStateRestorationTests {

    @get:Rule
    val composeTestRule = createComposeRule()

    @Test
    fun onRecreation_stateIsRestored() {
        val restorationTester = StateRestorationTester(composeTestRule)

        restorationTester.setContent { MainScreen() }

        // TODO: Run actions that modify the state

        // Trigger a recreation
        restorationTester.emulateSavedInstanceStateRestore()

        // TODO: Verify that state has been correctly restored.
    }
}

Tester différentes configurations d'appareils

Les applications Android doivent s'adapter à de nombreuses conditions changeantes: taille des fenêtres, paramètres régionaux, tailles de police, thèmes sombre et clair, etc. La plupart de ces conditions sont dérivées de valeurs au niveau de l'appareil contrôlées par l'utilisateur et exposées avec l'instance Configuration actuelle. Tester différentes configurations directement dans un test est difficile, car le test doit configurer des propriétés au niveau de l'appareil.

DeviceConfigurationOverride est une API réservée aux tests qui vous permet de simuler différentes configurations d'appareils de manière localisée pour le contenu @Composable en cours de test.

L'objet compagnon de DeviceConfigurationOverride possède les fonctions d'extension suivantes, qui remplacent les propriétés de configuration au niveau de l'appareil:

• DeviceConfigurationOverride.DarkMode(): force le système à utiliser le thème sombre ou le thème clair.
• DeviceConfigurationOverride.FontScale(): remplace l'échelle de police du système.
• DeviceConfigurationOverride.FontWeightAdjustment(): remplace l'ajustement de l'épaisseur de police du système.
• DeviceConfigurationOverride.ForcedSize(): force une quantité d'espace spécifique, quelle que soit la taille de l'appareil.
• DeviceConfigurationOverride.LayoutDirection(): remplace la direction de la mise en page (de gauche à droite ou de droite à gauche).
• DeviceConfigurationOverride.Locales(): remplace les paramètres régionaux.
• DeviceConfigurationOverride.RoundScreen(): force l'affichage si l'écran est rond.

Pour appliquer un forçage spécifique, encapsulez le contenu à tester dans un appel à la fonction de niveau supérieur DeviceConfigurationOverride(), en transmettant le forçage à appliquer en tant que paramètre.

Par exemple, le code suivant applique le forçage DeviceConfigurationOverride.ForcedSize() pour modifier la densité localement, forçant le composable MyScreen à être affiché dans une grande fenêtre en mode paysage, même si l'appareil sur lequel le test s'exécute n'est pas compatible avec cette taille de fenêtre directement:

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.ForcedSize(DpSize(1280.dp, 800.dp))
    ) {
        MyScreen() // Will be rendered in the space for 1280dp by 800dp without clipping.
    }
}
DeviceConfigurationOverrideSnippets.kt

Pour appliquer plusieurs forçages en même temps, utilisez DeviceConfigurationOverride.then():

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.FontScale(1.5f) then
            DeviceConfigurationOverride.FontWeightAdjustment(200)
    ) {
        Text(text = "text with increased scale and weight")
    }
}
DeviceConfigurationOverrideSnippets.kt

Autres ressources

• Tester des applications sur Android : la page de destination principale des tests Android offre une vue plus large des principes et des techniques de test.
• Principes de base des tests : découvrez les concepts fondamentaux des tests d'une application Android.
• Tests locaux:vous pouvez exécuter certains tests en local, sur votre propre poste de travail.
• Tests instrumentés:il est recommandé d'exécuter également des tests instrumentés. Il s'agit des tests qui s'exécutent directement sur l'appareil.
• Intégration continue : l'intégration continue vous permet d'intégrer vos tests à votre pipeline de déploiement.
• Testez différentes tailles d'écran:avec de nombreux appareils à la disposition des utilisateurs, vous devez tester différentes tailles d'écran.
• Espresso : bien que destiné aux UI basées sur les vues, les connaissances sur Espresso peuvent toujours être utiles pour certains aspects des tests Compose.