Notions de test de régression visuelle

Les tests de régression visuelle (VRT) détectent automatiquement les changements visuels involontaires entre différentes versions du code en comparant des captures d’écran rendues pixel par pixel. Ils détectent les régressions CSS — déplacements de mise en page, changements de couleur et espacements défectueux — que les tests unitaires ne détectent pas du tout.

VRT prend des captures d’écran de référence des composants ou des pages, puis de nouvelles captures après les changements de code et les compare. Les différences sont mises en évidence dans une image comparative. Les développeurs examinent ces différences et approuvent les changements intentionnels ou corrigent les régressions involontaires.

La comparaison pixel par pixel compare les images pixel par pixel : elle est sensible, mais sujette aux faux positifs dus à l’anticrénelage et aux différences de rendu des sous-pixels. Les outils de comparaison structurelle (Applitools AI) comparent l’intention visuelle plutôt que les pixels exacts, ce qui réduit les faux positifs liés aux variations du rendu des polices.

Les captures d’écran approuvées deviennent la nouvelle référence. Stockez les références dans le système de contrôle de version (Git LFS pour les images volumineuses) ou dans un service infonuagique dédié. Chaque PR affiche les différences par rapport à la référence, et les responsables approuvent ou refusent les changements visuels dans le cadre de la révision.

Les tests VRT au niveau du composant testent des composants d’interface isolés (avec Storybook). Les tests VRT au niveau de la page testent des pages complètes dans un véritable navigateur. Les tests de composants sont plus rapides et plus ciblés ; les tests de pages détectent les problèmes de mise en page liés à l’intégration entre les composants.

Testez tous les états visuels : par défaut, survolé, ciblé, actif, désactivé, en chargement, en erreur, vide et complet. Les états de survol nécessitent une simulation JavaScript (page.hover() dans Playwright). Une couverture incomplète des états crée des angles morts face aux régressions des états interactifs.

Rendez les captures d’écran dans plusieurs navigateurs (Chrome, Firefox, Safari) et fenêtres d’affichage (mobile, tablette, ordinateur). Les différences de rendu entre navigateurs peuvent provoquer des faux positifs : utilisez des références propres à chaque navigateur et configurez des seuils de comparaison qui tolèrent les variations de rendu connues.

Le rendu des polices diffère légèrement selon les combinaisons de système d’exploitation, de navigateur et de GPU. Utilisez des environnements d’intégration continue cohérents (Docker + une version précise de Chrome) pour éliminer les faux positifs dus à l’environnement. Les services VRT infonuagiques assurent automatiquement la cohérence de l’environnement.

Le contenu dynamique — horodatages, avatars d’utilisateurs, publicités et données aléatoires — provoque des faux positifs. Masquez les régions dynamiques avec une surcouche de couleur unie avant la capture d’écran. La plupart des outils VRT permettent de sélectionner les éléments à masquer.

Exécutez VRT dans l’intégration continue pour chaque PR. Faites échouer la compilation lorsque des différences visuelles non approuvées sont détectées. Transmettez les différences visuelles aux responsables de la conception et pas uniquement à l’équipe technique : les changements visuels relèvent autant de la conception que de l’ingénierie.

VRT offre le meilleur retour sur investissement dans les bibliothèques de composants et les systèmes de conception où la cohérence visuelle est une fonctionnalité du produit. Pour les pages marketing qui changent fréquemment, le coût de maintenance des références peut dépasser la valeur de détection des régressions.

Pourquoi les tests de régression visuelle produisent-ils des faux positifs dus aux différences de rendu des polices ?

Les tests de régression visuelle détectent les régressions du CSS et de la mise en page en comparant des captures d'écran entre différentes versions du code. Pour être efficace, VRT nécessite des environnements cohérents, une couverture des états, le masquage du contenu dynamique et un processus de revue qui achemine les différences vers des personnes chargées de la revue de conception — ce qui en fait un outil collaboratif d'assurance qualité, et pas seulement une barrière automatisée.