Test de capture d’écran avec Jetpack Compose

Qu’est-ce que le test de capture d’écran

Les tests de capture d’écran ou d’instantané sont un moyen d’automatiser la validation des composants et des widgets de l’interface utilisateur. Il empêche les régressions lors de la mise à jour d’un écran ou d’un composant existant. Un outil de test de capture d’écran permet de restituer un élément de l’interface utilisateur (un écran ou un composant), d’en prendre un instantané, puis de le comparer avec l’instantané correct existant. Si l’image ne correspond pas, le test échoue, alertant le développeur que quelque chose a changé visuellement. Les tests de capture d’écran peuvent être facilement intégrés au serveur CI pour être exécutés sur chaque build ou PR.

REMARQUE : une chose à comprendre ici est que les tests de capture d’écran ne sont qu’un autre type de tests unitaires pour vous assurer que les modifications de votre code fonctionnent correctement. Il ne remplace aucune méthodologie de test d’interface utilisateur existante.

Pour mettre les choses en perspective, vous trouverez ci-dessous une démonstration du fonctionnement d’un test de capture d’écran.

Rapport de test de capture d’écran (échec du test)

L’image de référence ici est la bonne à laquelle la dernière conception de l’interface utilisateur (image réelle) est comparée, et l’image différentielle montre les différences entre les deux captures d’écran (référence et réelle).
Le rapport de test ci-dessus montre que le test a échoué car le rayon du LoginButton dans l’image réelle n’est pas le même que celui de l’image de référence, et l’image diff met en évidence la même chose.

C’est tout pour l’introduction. Nous allons maintenant plonger dans l’outil de test de capture d’écran Compose Preview et apprendre comment nous pouvons l’utiliser dans notre projet pour créer et exécuter des tests de capture d’écran.

Test de capture d’écran de l’aperçu de composition

L’outil de test de capture d’écran Compose Preview a été récemment publié en version alpha, il est conçu pour être aussi facile à utiliser que les aperçus composables.

Pour utiliser les tests de capture d’écran Compose Preview, nous devons utiliser les éléments suivants : –
Android Gradle 8.5.0-beta01 ou plus tard.
Kotlin 1.9.20 ou plus tard

Installation

1. Ajouter le com.android.compose.screenshot plugin et ui-tooling dépendance à votre projet.

 [versions]
 agp = "8.5.0-beta01"
 kotlin = "1.9.20"
 screenshot = "0.0.1-alpha01"
 [plugins]
 screenshot = { id = "com.android.compose.screenshot", version.ref = "screenshot"}
 ...
 [libraries]
 androidx-compose-ui-tooling = { group = "androidx.compose.ui", name = "ui-tooling"}

Dans le fichier Gradle au niveau du module, ajoutez le plugin et la dépendance : –

 plugins {
   alias(libs.plugins.screenshot)
  }

  dependencies {
    screenshotTestImplementation(libs.androidx.compose.ui.tooling)
   }

2. Ensuite, nous devons activer la propriété expérimentale pour le test de capture d’écran dans le projet gradle.properties déposer.

android.experimental.enableScreenshotTest=true

3. Dans le bloc Android {} de votre niveau de module build.gradle.kts fichier, activez l’indicateur expérimental pour utiliser le screenshotTest ensemble de sources et assurez-vous que kotlinCompilerExtensionVersion est défini sur 1.5.4 ou version ultérieure.

 android {
 ...
 composeOptions {
 kotlinCompilerExtensionVersion = "1.5.4"
 }
 experimentalProperties["android.experimental.enableScreenshotTest"] = true
}

Création d’un test de capture d’écran

Avec cela, la configuration est terminée et nous sommes prêts à créer notre premier test de capture d’écran. Par souci de simplicité, nous utiliserons un simple widget pour effectuer le test. Nous allons créer un bouton Composable uniquement, et nous modifierons son rayon de bordure et son remplissage horizontal pour interrompre le test et visualiser le résultat du test.
Ci-dessous le composable que nous allons tester :

@Composable
fun PrimaryButton( title:String){
   Button(
     modifier = Modifier.fillMaxWidth(),
     onClick = {},
     shape = RoundedCornerShape(20.dp),
     ) {
        Text(title)
       }
 }

L’étape suivante consiste à créer un test de capture d’écran pour notre composable. Nous devons d’abord créer un nouveau jeu de sources, nommé screenshotTest à l’intérieur srcet créez un nouveau fichier de test en dessous.

Ensemble de sources de test de capture d’écran

Nous allons maintenant créer notre cas de test pour PrimaryButton Composable. Compose Preview Screenshot Testing est conçu pour être utilisé aussi facilement qu’un aperçu composable. Nous pouvons également utiliser @Preview paramètres, tels que uiMode ou fontScaleet bien plus encore pour nous aider à faire évoluer nos tests.

class PrimaryButtonScreenshotTest {
@Preview(showBackground = true)
@Composable
fun PrimaryButtonPreview() {
   MaterialTheme {
     PrimaryButton("Login")
     }
   }
}

Génération d’une capture d’écran de référence

Maintenant que notre test est en place, nous allons générer une capture d’écran pour notre aperçu. Cette capture d’écran sera ensuite utilisée pour comparer avec la nouvelle lorsque nous apporterons des modifications à notre composable. Pour générer une capture d’écran, nous devons exécuter la commande ci-dessous.

./gradlew updateDebugScreenshotTest

Après avoir exécuté cette commande, vous pouvez voir qu’une image png est générée sous la même source de capture d’écran définie dans le répertoire de référence.

Image de référence générée

Validation de la capture d’écran pour le test

Maintenant que notre image de référence est générée, nous pouvons valider notre implémentation actuelle de composable par rapport à elle.
nous devons exécuter la commande suivante pour valider : –

./gradlew validateDebugScreenshotTest

Après avoir exécuté cette commande, nous pouvons vérifier l’état du test dans la console et également obtenir le rapport généré. Le rapport HTML généré peut être trouvé à l’adresse {module}/build/reports/screenshotTest/preview/{variant}/index.html

Test réussi (build/reports/screenshotTest/preview/index.html)

Comme nous n’avons encore apporté aucune modification à notre Composable, le test a réussi. Nous allons maintenant apporter quelques modifications au composable testé, qui est un bouton. Nous allons changer son rayon de bordure à 30 dp et nous y ajouterons 20 dp de remplissage horizontal.

@Composable
fun PrimaryButton( title:String){
  Button(
    modifier = Modifier.fillMaxWidth().padding(horizontal = 20.dp),
    onClick = {},
    shape = RoundedCornerShape(30.dp),
       ) {
          Text(title)
         }
  }

Exécuter à nouveau la même commande –
./gradlew validateDebugScreenshotTest

Le test a échoué (build/reports/screenshotTest/preview/index.html)

nous pouvons voir que le test a échoué car l’aperçu Composable ne correspond pas à la capture d’écran précédente prise. Cet échec indique que quelque chose de visuel a changé dans notre composable. Nous pouvons visualiser le rapport pour découvrir exactement ce qui a fait échouer le test et le gérer en conséquence et éviter toute régression de l’interface utilisateur.

Note

Nous avons utilisé les deux commandes ci-dessus : updateDebugScreenshotTest et validateDebugScreenshotTest. Lorsqu’il s’agit d’automatiser ces deux tâches, validateDebugScreenshot Les tests peuvent être automatisés pour être exécutés avec le serveur CI à chaque demande d’extraction ou build (en l’abandonnant si le test échoue).
Automatisation updateDebugScreenshotTest peut causer des problèmes. Si nous mettons à jour les images de référence à chaque fois, nous perdrons l’ancienne référence et le test risque de ne pas s’exécuter sur la bonne capture d’écran.

Nous devrions courir updateDebugScreenshotTest uniquement dans les cas suivants :

1. Lorsque vous apportez des modifications à un composant dans un système de conception.
2. Lors de l’ajout ou de la suppression de composants d’un écran existant.
3. Lors de la création d’un nouveau composant ou écran, que nous testerons plus tard.

Conclusion

C’est ça. La création et l’exécution de tests de capture d’écran pour Composable impliquent uniquement ces étapes. Grâce à ces tests, nous pouvons améliorer le processus de test de l’interface utilisateur en détectant les régressions visuelles rapidement et avec très peu d’effort.

VOUS TROUVEZ CECI UTILE ? PARTAGEZ-LE