MAISON CODE .
/ Tech · QA · Testing · Storybook · CSS

Tests de régression visuelle : Pixel Perfect Forever

Les tests unitaires vérifient la logique. Les tests E2E vérifient les flux. Les tests de régression visuelle vérifient les pixels. Comment détecter les régressions CSS avant qu'elles n'atteignent la production.

AB
Alex B.
Tests de régression visuelle : Pixel Perfect Forever

Pourquoi Maison Code en parle

Chez Maison Code Paris, nous agissons comme la conscience architecturale de nos clients. Nous héritons souvent de stacks “modernes” construites sans compréhension fondamentale de l’échelle.

Nous abordons ce sujet car il représente un point de pivot critique dans la maturité de l’ingénierie. Une mise en œuvre correcte différencie un MVP fragile d’une plateforme résiliente de niveau entreprise.

Le problème des “fuites CSS”

Vous êtes développeur. Vous disposez d’un composant Button utilisé à 50 endroits. Ça a l’air super. Un jour, l’équipe Marketing vous demande de modifier la marge du Footer pour faire respirer le texte du copyright. Vous allez sur global.css. Vous voyez une classe générique « .container ». Vous ajoutez « marge-bas : 20px ». Vous poussez le code. Sans le savoir, le « Button » était imbriqué dans un « .container ». Désormais, chaque bouton de l’application dispose d’une marge supplémentaire de 20 px. La mise en page sur le modal « Inscription » est maintenant interrompue. Le bouton est poussé hors de l’écran. La réussite des tests unitaires : le composant bouton rendu sans crash. La réussite des tests E2E : Puppeteer pourrait faire défiler jusqu’au bouton et cliquer dessus par programme (les robots ne se soucient pas des changements de disposition). L’expérience utilisateur a échoué : l’utilisateur pense que votre application est en panne. Il s’agit de Régression visuelle. Les humains sont notoirement mauvais pour repérer ces changements subtils (« Change Blindness »). Détecter qu’une taille de police est passée de 14 px à 13 px sur 100 pages est impossible pour un réviseur humain. Les tests de régression visuelle automatisent cela. Il s’agit de prendre une capture d’écran de l’état « Approuvé » (Baseline) et de la comparer pixel par pixel avec l’état « Nouveau ». Si même 1 % des pixels sont différents, le test échoue et vous montre un « Diff » rouge.

Pourquoi Maison Code discute des tests visuels

Chez Maison Code, nous travaillons avec des Marques de luxe. Pour un tableau de bord SaaS, un bouton mal aligné est peut-être acceptable. Pour une maison de mode, L’esthétique est fonctionnelle. L’identité de la marque est le produit. Si le logo est mal aligné de 2 pixels ou si l’épaisseur de la police ne correspond pas aux directives d’impression, cela nuit à la valeur de la marque. Les clients nous paient pour “Pixel Perfection”. Nous ne pouvons pas compter sur le contrôle qualité manuel pour détecter “L’espacement des lettres est décalé de 0,1em”. Nous mettons en œuvre des pipelines de régression visuelle automatisés (en utilisant Percy ou Chromatic) pour garantir qu’aucun « accident CSS » n’atteint jamais la production. Nous rendons le Design System immuable.

L’outil : Storybook + Chromatique (ou Percy)

Commencez par Storybook. Storybook est un atelier permettant de créer des composants d’interface utilisateur de manière isolée. Vous créez une « histoire » pour chaque état de votre composant. Bouton.stories.tsx :

  • ‘Primaire’ (Bleu).
  • Secondaire (Fantôme).
  • Destructeur (Rouge).
  • Chargement (Spinner).
  • Désactivé (Gris).

Chromatic (créé par les responsables de Storybook) est le cloud runner. Il s’intègre à votre CI (GitHub Actions).

  1. Build : CI crée le site statique Storybook.
  2. Télécharger : CI le télécharge sur Chromatic Cloud.
  3. Rendu : Chromatic fait tourner les navigateurs cloud (Chrome, Firefox, Edge, Safari).
  4. Capture : il restitue chaque histoire et prend une capture d’écran en pleine résolution.
  5. Comparer : il compare ces captures d’écran à la “Baseline” (le dernier commit sur main).
  6. Rapport : si les pixels ont changé, l’état de la construction est « En attente de révision ».

Le workflow : examen des différences

Le développeur ouvre le tableau de bord Chromatic. Ils voient « Bouton (primaire) modifié ». Ils activent la « Vue différentielle » (Diapositive/Superposition). Ils voient les pixels rouges indiquant le décalage. Scénario A (accidentel) : “Oups, j’ai cassé le rembourrage.” -> Action : Rejeter. Revenez au code. Corrigez CSS. Scénario B (intentionnel) : “Oui, j’ai intentionnellement augmenté la taille de la police.” -> Action : Accepter. Cette action « Accepter » met à jour la ligne de base. Les futures versions seront comparées à cette nouvelle version. Cela crée une piste d’audit visuelle. Vous savez exactement quand le bouton a changé et qui l’a approuvé.

Gestion des données dynamiques (The Flakiness)

Les tests visuels détestent les données dynamiques. Si votre composant affiche Date.now(), chaque capture d’écran échouera. Si votre composant restitue Math.random(), il échoue. S’il charge un avatar d’utilisateur depuis « randomuser.me », il échoue. Solution : Données simulées. Vos histoires doivent être Déterministes. Passez les accessoires codés en dur. date="2025-01-01T12:00:00Z". Réponses d’API simulées à l’aide de Mock Service Worker (MSW) pour renvoyer toujours le même JSON. Geler les animations. Une capture d’écran prise à « 0,1 s » d’une animation de fondu entrant sera différente de « 0,2 s ». Désactivez les animations dans l’environnement de test.

/* aperçu-head.html dans Storybook */
<style>
  *, *::avant, *::après {
    animation : aucune !important ;
    transition : aucune !important ;
  }
</style>

Tests multi-navigateurs

Cela fonctionne sur votre Mac (Chrome). Est-ce que ça marche sous Windows (Edge) ? Ou iPhone (Safari) ? Les navigateurs affichent les polices et les ombres différemment. Les outils de régression visuelle exécutent le rendu dans plusieurs navigateurs réels dans le cloud. Ils détectent des bogues spécifiques au navigateur. “Le dégradé manque sur Safari.” “La grille est cassée sur Firefox.” Vous bénéficiez de cette couverture gratuitement sans posséder de Device Lab.

Tests réactifs

Il ne suffit pas de tester sur Desktop (1920px). Vous devez tester sur tablette (768px) et mobile (375px). Votre grille pourrait s’effondrer en une pile. Votre menu pourrait se transformer en hamburger. Chromatic vous permet de spécifier des fenêtres. fenêtres : [375, 768, 1200]. Il faudra 3 captures d’écran par composant. Cela triple votre couverture. Vous détecterez instantanément les bugs « Le bouton chevauche le texte sur l’iPhone SE ».

Le point de vue du sceptique

“C’est trop cher. En argent et en temps.” Contre-point : Argent : Oui, Chromatic/Percy coûte de l’argent (utilisation d’un instantané). Comparez cela au salaire d’un ingénieur QA cliquant manuellement sur 500 écrans sur 3 navigateurs. Ou le coût d’un “Hotfix” lorsque vous cassez l’interface utilisateur de Checkout en production. Durée : l’examen des instantanés prend 1 minute. “Ouais, ça a l’air bien.” Le débogage d’un bug de mise en page en production prend 3 heures. Les tests visuels constituent un levier important. Il détecte les bugs que les machines (tests unitaires) ne peuvent pas voir.

##FAQ

Q : Puis-je utiliser Playwright pour cela ? R : Oui (expect(page).toHaveScreenshot()). Le dramaturge est génial. Différence : Tests visuels du dramaturge/Cypress : idéal pour les pages complètes (intégrations). « La page d’accueil semble-t-elle correcte ? » Storybook/Chromatic : Idéal pour la bibliothèque de composants (Atoms). “Le composant spécifique “Alerte” semble-t-il correct dans les 5 variantes ?” Nous recommandons les deux. Utilisez Chromatic pour votre système de conception. Utilisez Playwright pour les flux d’utilisateurs critiques (Checkout).

Q : Comment gérer les différences d’anticrénelage de 1 px ? R : Le rendu du texte est difficile. Les différences de GPU entraînent des décalages de 1 px. Les outils ont des paramètres de « seuil ». seuil : 0,1. (Ignorer les différences inférieures à 0,1 %). Ils disposent également d’algorithmes de « détection d’anticrénelage » pour ignorer le bruit de lissage des polices.

Conclusion

Les tests de régression visuelle activent le « CSS sans peur ». Vous pouvez refactoriser l’intégralité de votre architecture SASS vers Tailwind, et si les captures d’écran correspondent à 100 %, vous savez avec une certitude mathématique que vous n’avez rien cassé. Il apporte de la rigueur technique à la conception. Arrêtez de plisser les yeux sur votre écran. Laissez le robot le faire.

13. Gestion des faux positifs (la règle du 1 %)

Parfois, des décalages de 1 px sont inévitables (mises à jour du moteur de rendu du navigateur). Nous fixons un seuil de 1 %. Si la différence est < 1 % du total des pixels, le test réussit automatiquement. Cela filtre le “bruit” (différences d’anti-aliasing) mais capture les “signaux” (bouton manquant). Nous utilisons également des Régions de mise en page. Nous disons à l’outil : “Ignorez le pied de page (il a une année de droit d’auteur dynamique). Vérifiez tout le reste.” Ce « test ciblé » réduit la desquamation de 90 %.

14. Pourquoi Chromatic est meilleur que le bricolage

Nous avons essayé de le construire nous-mêmes avec Puppeteer + AWS S3. C’était un cauchemar. Gestion des références, parallélisation de 500 captures d’écran, gestion des branches git… Chromatic résout ce problème. Il est construit par les responsables de Storybook. Il gère “l’historique Git” de manière native. Il sait que la « branche de fonctionnalités A » doit être comparée à la « branche principale » et non à la « branche de fonctionnalités B ». Le coût de 300 €/mois permet d’économiser 5 000 €/mois en salaire DevOps.

15. Conclusion

Le problème avec les tests visuels est le « bruit ». Si vous capturez du contenu dynamique, vous obtenez des faux positifs. Nous implémentons l’isolation des composants. Nous masquons les régions dynamiques avec CSS : .dynamic-ad-slot { visibilité : cachée ; }. Ou nous nous moquons des données pour les rendre statiques. Nous utilisons également des lignes de base spécifiques à la branche. Lors du développement d’une branche de fonctionnalités feat-new-header, nous comparons avec main. Si l’en-tête change, le test échoue. Nous le marquons comme « Accepté » dans la branche. Lorsque nous fusionnons avec « principal », cet instantané accepté devient la nouvelle référence.

14. Le retour sur investissement des tests visuels

Il en coûte 300 €/mois pour Chromatic. Cela semble beaucoup. Comparez-le à :

  1. Dommages à la marque : une marque de luxe avec une mise en page cassée ressemble à un site frauduleux.
  2. Dev Time : passer 4 heures à corriger une régression causée par un changement CSS global.
  3. QA Time : payer un humain pour vérifier 500 écrans. Le retour sur investissement est généralement de 10x. Il vous permet de déployer le vendredi sans crainte.

15. Conclusion

Si vous en avez assez des cycles « J’ai réparé l’en-tête mais j’ai cassé le pied de page », Maison Code peut implémenter un pipeline de tests visuels. Nous mettons en place des flux de travail Storybook, Chromatic et CI pour verrouiller votre conception en place. Nous définissons les lignes de base et formons votre équipe sur la façon d’examiner les différences.

Engagez nos Architectes.