Tests Visuels dans les Design Systems : Composants Isolés vs Pages Complètes
Le test visuel d'un design system est la pratique de vérifier automatiquement l'apparence de chaque composant UI — boutons, formulaires, cartes, modales — à la fois en isolation (dans Storybook ou équivalent) et en contexte réel (dans les pages de l'application), pour détecter les régressions visuelles à chaque modification.
Les design systems sont devenus le standard pour les équipes front-end. Un ensemble de composants réutilisables, documentés, versionnés. C'est propre. C'est maintenable. Et pourtant, les bugs visuels passent quand même. Voici pourquoi.
Le piège du composant parfait en isolation
Vous avez un composant "Card" dans votre design system. Vous le testez dans Storybook. Il est parfait : les marges sont correctes, les couleurs respectent la charte, la typographie est conforme. Tout est vert.
Vous l'intégrez dans une page avec une grille de 3 colonnes, un sidebar et un header. Et là, la Card déborde de sa colonne. Le texte se chevauche avec le composant voisin. Le bouton d'action est partiellement masqué par le footer.
Le composant est parfait. La page est cassée. Le test en isolation ne pouvait pas détecter ça.
C'est le piège fondamental : un composant n'existe jamais seul. Il interagit avec ses voisins, avec le layout parent, avec le contenu réel. Tester en isolation, c'est tester dans un vide qui n'existe pas en production.
Pourquoi les deux niveaux sont nécessaires
Le test de composants isolés répond à une question : "Est-ce que le composant lui-même s'affiche correctement dans tous ses états ?" Bouton actif, inactif, survol, focus. Card avec titre court, titre long, sans image. Modal ouverte, fermée. Ces tests protègent le design system en tant que librairie.
Le test de pages complètes répond à une question différente : "Est-ce que les composants fonctionnent ensemble dans le contexte réel de l'application ?" Le layout tient-il ? Les composants ne se chevauchent-ils pas ? Le responsive fonctionne-t-il quand 5 composants partagent le même espace ?
Les deux questions sont légitimes. Et ni l'une ni l'autre ne couvre le spectre complet seule.
Les outils de chaque niveau
Pour les composants isolés, Chromatic (intégré à Storybook) est la référence. Chaque story devient automatiquement un test visuel. C'est efficace pour protéger la librairie de composants.
Pour les pages complètes, il faut un outil qui teste de vraies pages avec de vrais parcours utilisateur. C'est le domaine de Delta-QA (sans code), de Playwright (avec code) ou de Percy (SaaS).
Le problème que beaucoup d'équipes rencontrent : elles investissent massivement dans le test de composants via Chromatic, et négligent le test de pages complètes. Résultat : la librairie est protégée, mais l'application ne l'est pas.
Les régressions que seules les pages complètes détectent
Les conflits de layout entre composants voisins. Deux composants qui fonctionnent parfaitement en isolation mais qui se chevauchent quand ils partagent une grille CSS.
Les effets de cascade CSS. Un changement de style sur un composant parent qui impacte le rendu de tous ses enfants. En isolation, le composant enfant n'a pas de parent — le bug est invisible.
Les problèmes de responsive en contexte réel. Un composant qui est responsive en isolation (il s'adapte à la largeur de son conteneur) mais qui casse quand son conteneur lui-même change de taille en fonction du viewport.
Le contenu réel vs le contenu de démo. Les stories Storybook utilisent des données de démonstration propres et calibrées. En production, les utilisateurs mettent des titres de 200 caractères, des images en portrait au lieu de paysage, du texte en arabe qui inverse la direction.
La stratégie recommandée
Utilisez Chromatic (ou équivalent) pour protéger votre librairie de composants. Chaque composant, chaque état, chaque variation. C'est le premier filet de sécurité.
Utilisez un outil de test de pages complètes pour protéger l'application elle-même. Les pages critiques, les parcours utilisateur principaux, les layouts complexes. C'est le deuxième filet.
Ni l'un ni l'autre ne suffit seul. Ensemble, ils couvrent le spectre complet.
FAQ
Chromatic suffit-il si on utilise Storybook ?
Pour protéger la librairie de composants, oui. Pour protéger l'application complète, non. Les bugs de layout, de cascade CSS et de contenu réel ne sont visibles qu'au niveau de la page.
Faut-il tester tous les composants visuellement ?
Concentrez-vous sur les composants partagés (Button, Input, Card, Modal, Table) et ceux avec beaucoup d'états. Les composants simples et rarement modifiés peuvent être exclus.
Comment tester les pages complètes sans code ?
Avec un outil comme Delta-QA. Vous naviguez sur la page, l'outil capture l'état, et il compare automatiquement lors des exécutions suivantes. Pas besoin de Storybook ni de code.
Le test de composants détecte-t-il les problèmes de thème ?
Oui, si vous avez des stories pour chaque thème (clair/sombre). Mais il ne détecte pas les problèmes de thème en contexte — par exemple un composant qui bascule mal de thème quand il est imbriqué dans un autre.
Un design system protège la cohérence. Le test visuel protège la réalité. Tester vos composants en isolation, c'est vérifier que les briques sont bonnes. Tester vos pages complètes, c'est vérifier que la maison tient debout.
Essayer Delta-QA Gratuitement →
Article précédent : Outils de Test Visuel Gratuits