Les tests de capture d'écran sont un moyen très efficace de vérifier l'interface utilisateur de votre application. Les tests de captures d'écran peuvent exister dans les tests de composant, de fonctionnalité et d'application.
Vous pouvez utiliser des outils tiers pour créer des tests de capture d'écran instrumentés et locaux. Si vous utilisez Compose, vous pouvez utiliser l'outil de test officiel des captures d'écran de l'aperçu de Compose.
Définition
Les tests de capture d'écran consistent à prendre une capture d'écran d'une UI et à la comparer à une image précédemment approuvée, appelée "référence" ou "image de référence":
Si les images sont identiques, le test réussit. En cas de différences, l'outil crée un rapport:
Avec le rapport, vous avez deux réponses possibles:
- Comprenez qu'il y a une erreur dans le nouveau code et corrigez-la.
- Approuvez la nouvelle capture d'écran et remplacez l'image de référence par la nouvelle.
Les tests de capture d'écran ont un workflow différent des tests standards, car un test qui échoue ne signifie pas toujours qu'il y a une erreur.
Avantages
Les avantages des tests de capture d'écran sont les suivants:
- Un test de capture d'écran effectue plusieurs assertions par test. Par exemple, un seul test peut vérifier les couleurs, les marges, les tailles et les polices.
- Un test de capture d'écran est beaucoup plus facile à écrire, à comprendre et à gérer qu'un test de comportement équivalent.
- Ils sont particulièrement utiles pour vérifier et détecter les régressions sur différentes tailles d'écran.
Inconvénients
Cependant, les tests de capture d'écran peuvent également présenter des inconvénients:
- Gérer les images de référence peut être fastidieux, car un grand projet peut se terminer par des milliers de fichiers PNG.
- Les différentes plates-formes (Linux, Max et Windows) produisent des captures d'écran légèrement différentes.
- Ils sont plus lents que les tests de comportement équivalents.
- Un grand nombre de tests de captures d'écran peut poser problème, par exemple lorsqu'une seule modification affecte des milliers de captures d'écran.
Les sections suivantes fournissent des recommandations pour résoudre ces problèmes.
Limitez les tests de capture d'écran
Vous devez réduire le nombre de tests de captures d'écran tout en optimisant les commentaires et la couverture des régressions.
Les combinaisons de différents états d'interface utilisateur peuvent augmenter très rapidement le nombre de tests. Voici quelques-unes des façons de vérifier une partie de l'interface utilisateur de votre application:
- sur différents thèmes ;
- Utiliser différentes tailles de police
- Dans différentes tailles d'écran ou limites
Si vous faites cela pour chaque composant, mise en page et écran de votre application, vous vous retrouvez avec des milliers de fichiers de captures d'écran, dont la plupart ne vous fournissent aucune information supplémentaire.
Par exemple, si vous souhaitez tester un bouton personnalisé avec des thèmes clair et sombre, et avec trois tailles de police, vous n'avez pas besoin de les combiner. Vous pouvez choisir un seul thème. En effet, la façon dont le bouton réagit aux mots longs n'a aucun effet sur le thème.
Images de référence des magasins
Les images de référence (ou images d'or) sont généralement des fichiers PNG pouvant être enregistrés dans votre système de gestion de code source. Cependant, Git et la plupart des outils de gestion du contrôle des sources sont optimisés pour les fichiers texte, et non pour les fichiers binaires volumineux.
Pour gérer ces fichiers, vous disposez de trois options:
- Continuez à utiliser git, mais en essayant de minimiser l'utilisation de l'espace de stockage.
- Utilisez Git LFS.
- Utilisez un service cloud pour gérer les captures d'écran.
Différences avec la plate-forme Android
Les tests de captures d'écran reposent sur des API de plate-forme de bas niveau pour dessiner des fonctionnalités spécifiques telles que du texte ou des ombres. Les plates-formes peuvent les implémenter de différentes manières. Si vous développez sur un Mac et enregistrez de nouvelles captures d'écran prises en local, vous risquez de voir des tests défectueux sur une machine CI Linux.
Vous pouvez contourner ce problème de deux façons:
- Tolérer les petits changements
- Prendre des captures d'écran sur un serveur
Tolérer les petits changements
Vous pouvez configurer la plupart des bibliothèques de test de captures d'écran pour permettre de petites différences lors de la comparaison de deux captures d'écran.
Pour cela, il existe deux approches:
- Configurez une tolérance basée sur un pourcentage de pixels modifiés ou un pourcentage de la différence totale entre les valeurs en pixels.
- Utilisez une différence intelligente (l'algorithme qui compare les captures d'écran) pour vérifier la similitude structurelle et sémantique au lieu des pixels.
L'inconvénient de cette approche est qu'elle peut créer des faux positifs et ne pas détecter les erreurs qui sont en dessous du seuil ou considérées à tort comme suffisamment similaires.
Prendre des captures d'écran sur un serveur
Pour utiliser un comparateur de captures d'écran au pixel près, vous devez vous assurer que vos tests prennent des captures d'écran dans les mêmes conditions. Pour ce faire, vous pouvez utiliser votre système d'intégration continue (CI) ou un service cloud.
Par exemple, vous pouvez créer une étape dans votre workflow d'intégration continue qui effectue les opérations suivantes:
- Exécute les tests de capture d'écran (nécessaires uniquement si la mise en correspondance au pixel près n'est pas utilisée).
- Enregistre de nouvelles captures d'écran si l'étape précédente a échoué.
- Valide les nouveaux fichiers dans la branche.
Avec cette approche, les tests de capture d'écran ne échouent jamais en intégration continue, mais ils modifient la modification à votre place. De cette façon, vous et les examinateurs de modifications pouvez accepter les nouvelles captures d'écran en fusionnant les modifications.
Outils de test des captures d'écran
Tenez compte des principales différences suivantes entre les outils et les bibliothèques disponibles pour les tests de captures d'écran:
- Environnement: tests locaux exécutés sur l'hôte ou tests d'instrumentation exécutés sur un émulateur ou un appareil.
- Moteur de rendu: les solutions de capture d'écran côté hôte peuvent utiliser Layoutlib (le moteur de rendu d'Android Studio pour les aperçus) ou Robolectric Native Graphics (RNG).
- Les frameworks basés sur Layoutlib se concentrent sur le rendu de composants statiques, en utilisant différents états pour afficher un comportement différent. Ils sont généralement plus faciles à utiliser.
- Les frameworks qui s'intègrent à RNG peuvent utiliser toutes les fonctionnalités de Roboelectric, ce qui permet d'effectuer des tests plus vastes.