Créer un environnement de développement plus sûr et plus efficace avec les comparaisons visuelles de Playwright

Contexte et identification du problème

• Les tests frontend sont difficiles en raison des changements d’UI et des entrées utilisateur imprévisibles.
• Les tests vérifiés manuellement ont leurs limites, d’où l’idée d’introduire des tests automatisés.
• Les tests E2E existants basés sur l’enregistrement (TestProject, Playwright) ont un coût de maintenance élevé et sont fragiles face aux changements d’UI.

Adoption de Playwright Visual Comparisons

• Mise en place d’une approche de tests de régression visuelle pour détecter les changements d’UI.
• Stockage de captures d’écran de référence, puis comparaison après modification du code pour détecter les changements.
• Comparaison d’images possible via les modes 2-up, Swipe, Highlight et Onion Skin.

Principaux problèmes rencontrés lors de l’adoption et solutions

1. Faux échecs causés par des écarts minimes (0,01 %)
   Problème : des différences de rendu des polices apparaissaient selon l’environnement d’exécution des tests (OS, navigateur, paramètres d’affichage, etc.).
   Solution : utilisation de conteneurs Docker pour exécuter tous les tests dans un environnement identique.

2. Nécessité de prendre la capture après le chargement complet des données
   Problème : si la capture était prise avant le chargement complet de la page, l’UI de chargement pouvait y apparaître.
   Solution : attente de l’apparition d’une chaîne spécifique via une fonction utilitaire utilisant getByText + toBeVisible.

3. Différences de capture causées par les éléments animés
   Problème : les éléments CSS animés, Canvas, SVG et WebGL étaient capturés à des instants différents à chaque fois, ce qui rendait les tests flaky.
   Solution : mise en place de divers traitements pour désactiver les animations, ainsi que d’optimisations complémentaires de l’exécution des tests.

4. Détection inutile de changements à cause de plugins tiers (iframe, etc.)
   Problème : des plugins tiers, comme les retours clients, enquêtes ou chatbots, étaient chargés via des iframe et généraient des variations visuelles.
   Solution : lors de la génération des captures, application d’un CSS commun pour masquer les iframe et certains éléments de plugins.

5. Échec de validation des éléments du bas sur les pages avec défilement
   Problème : toHaveScreenshot ne capture par défaut que la zone actuellement visible, ce qui nécessitait une gestion liée au scroll.
   Solution : application de l’option fullPage: true pour capturer une capture d’écran de la page entière.

Conclusion

• Les tests de régression visuelle ont permis d’automatiser efficacement la détection des changements d’UI.
• Ce n’est pas une solution parfaite, mais elle améliore à la fois la productivité du développement et la stabilité des tests.
• Des améliorations continues et une optimisation de l’environnement de test restent nécessaires.