Chapitre 75 : Arbitrage : Tests visuels automatisés vs tests unitaires de styles

Comparaison des approches de validation de la qualité visuelle : quand privilégier la précision du contrat technique face à la fidélité du rendu utilisateur.

En tant qu'ingénieur front-end senior, l'un des défis les plus complexes n'est pas d'écrire du CSS, mais de garantir que ce dernier ne "casse" pas d'autres parties de l'application lors d'une modification. Le CSS, par nature globale et en cascade, est sujet à des effets de bord imprévisibles.

Pour pallier cela, deux stratégies s'opposent et se complètent : les tests unitaires de styles (vérification de propriétés spécifiques) et les tests de régression visuelle (comparaison de captures d'écran). L'arbitrage entre ces deux méthodes repose sur un équilibre entre coût de maintenance, vitesse d'exécution et niveau de confiance.

L'approche par Tests Unitaires de Styles

1. Quoi

Le test unitaire de style consiste à vérifier programmatiquement qu'un élément possède une propriété CSS spécifique ou une classe donnée dans un état précis. On ne regarde pas l'image, on interroge le DOM et le Computed Style (le style final calculé par le navigateur).

2. Pourquoi

L'objectif est de valider un contrat technique. C'est particulièrement utile pour :

• Les Design Systems : s'assurer qu'une variable de couleur --color-primary est bien appliquée au composant Button.
• La logique conditionnelle : vérifier qu'une classe .is-disabled applique bien un pointer-events: none.
• La compatibilité : s'assurer que des fallback sont présents.

3. Comment

A. Syntaxe de base (avec Jest et JSDOM)

Dans un environnement JSDOM, on utilise souvent getComputedStyle pour vérifier le rendu final.

test('le bouton primaire doit avoir la couleur de marque', () => {
  document.body.innerHTML = '<button class="btn-primary">Click me</button>';
  const btn = document.querySelector('.btn-primary');
  const styles = window.getComputedStyle(btn);
  
  // On vérifie la valeur calculée
  expect(styles.backgroundColor).toBe('rgb(0, 123, 255)'); 
});

B. Cas concret : Validation d'un système de thémisation

Imaginons un composant qui change de style selon un attribut data-theme.

import { render, screen } from '@testing-library/react';
import { ThemeProvider } from './ThemeProvider';
import { Button } from './Button';

describe('Button Theme Integration', () => {
  it('should apply dark theme colors when theme is set to dark', () => {
    render(
      <ThemeProvider theme="dark">
        <Button>Test</Button>
      </ThemeProvider>
    );

    const button = screen.getByRole('button');
    const styles = window.getComputedStyle(button);

    // On valide que la variable CSS est correctement résolue
    // Note : JSDOM a des limitations sur le calcul des variables CSS, 
    // on vérifie souvent la présence de la classe ou l'attribut.
    expect(button).toHaveClass('theme-dark');
    expect(styles.color).toBe('rgb(255, 255, 255)');
  });
});

C. Limitations

Le test unitaire de style souffre de deux problèmes majeurs :

1. La Tautologie : Tester que .btn { color: red } a une couleur rouge revient à tester que vous savez écrire du CSS. C'est un test à faible valeur ajoutée.
2. L'aveuglement visuel : Un test unitaire peut passer alors que l'élément est masqué par un autre (z-index), positionné hors écran, ou rendu illisible par un contraste insuffisant.

4. Zone de Danger

❌ Erreur commune : Vouloir tester chaque propriété CSS d'un composant en unitaire. Cela crée une suite de tests extrêmement fragile qui casse à chaque modification mineure de design (refactoring coûteux).

✅ Bonne pratique : Ne tester en unitaire que les propriétés critiques liées à l'accessibilité (ex: aria-hidden, display: none sur les éléments masqués) ou les contrats de Design System.

---

L'approche par Tests de Régression Visuelle (VRT)

1. Quoi

Le Visual Regression Testing (VRT) consiste à prendre une capture d'écran d'un composant (le "Baseline") et à la comparer pixel par pixel avec une nouvelle capture prise après une modification du code. Si la différence dépasse un certain seuil (threshold), le test échoue.

2. Pourquoi

C'est la seule méthode capable de détecter les effets de bord globaux. Puisque le CSS est global, modifier une marge dans un fichier global.css peut décaler un élément dans une page totalement différente. Le VRT capture l'expérience utilisateur réelle.

3. Comment

A. Flux de fonctionnement

Le VRT suit généralement ce cycle :

1. Capture : Le moteur (Playwright, Cypress, Percy) rend la page.
2. Comparaison : Comparaison de l'image actuelle vs l'image de référence.
3. Diff : Génération d'une image "diff" mettant en évidence les pixels modifiés.
4. Approbation : Le développeur valide si le changement est voulu (mise à jour du baseline).

B. Cas concret : Configuration Playwright

Voici comment implémenter un test de capture d'écran robuste.

import { test, expect } from '@playwright/test';

test('le header doit rester identique malgré les changements de styles', async ({ page }) => {
  await page.goto('/components/header');
  
  // On attend que les polices et images soient chargées pour éviter le flakiness
  await page.waitForLoadState('networkidle');

  // Capture d'écran du composant spécifique
  const header = page.locator('header');
  
  // compare l'image actuelle avec le snapshot enregistré
  await expect(header).toHaveScreenshot('header-baseline.png', {
    maxDiffPixels: 100, // Tolérance pour les micro-variations de rendu
    threshold: 0.2,     // Sensibilité du changement de couleur
  });
});

C. Limitations

• Flakiness (Instabilité) : Le rendu peut varier selon l'OS, la version du navigateur ou même le moteur de rendu des polices (anti-aliasing).
• Lenteur : Prendre des captures d'écran est beaucoup plus lent que d'interroger le DOM.
• Maintenance : Chaque changement de design volontaire nécessite de mettre à jour manuellement les baselines.

4. Zone de Danger

❌ Erreur commune : Faire des captures d'écran de pages entières. Le moindre changement dans le footer fera échouer tous les tests de toutes les pages.

✅ Bonne pratique : Isoler les composants dans des outils comme Storybook et effectuer des captures d'écran atomiques.

---

Arbitrage Tests Unitaires vs Visuels

Matrice de Décision pour l'Arbitrage

Pour choisir la stratégie, utilisez le tableau suivant :

Critère	Test Unitaire de Style	Test de Régression Visuelle
Vitesse d'exécution	Très rapide (ms)	Lent (secondes/minutes)
Précision technique	Haute (valeur exacte)	Moyenne (pixel diff)
Détection d'effets de bord	Nulle	Excellente
Coût de maintenance	Élevé (si trop détaillé)	Moyen (mise à jour baselines)
Fiabilité (Flakiness)	Très stable	Sujet aux variations d'OS/GPU
Objectif	"Est-ce que la règle est là ?"	"Est-ce que ça a l'air correct ?"

Stratégie d'implémentation Senior

Une architecture de test mature ne choisit pas l'un ou l'autre, mais distribue les tests selon la Pyramide des Tests adaptée au CSS :

1. Base (Tests Unitaires / Linters) :
   • Utiliser Stylelint pour interdire les mauvaises pratiques (ex: éviter !important).
   • Tester les variables CSS et les contrats de thèmes.
2. Milieu (Tests de Composants / VRT Atomique) :
   • Utiliser Storybook + un outil de VRT (Chromatic, Playwright) pour valider chaque état d'un composant (Hover, Active, Disabled).
3. Sommet (VRT de Pages / E2E) :
   • Captures d'écran des parcours critiques (Checkout, Login) pour s'assurer que l'assemblage des composants ne crée pas de collision visuelle.

Questions clés

1. Pourquoi un test unitaire de style peut-il passer alors que l'élément est invisible pour l'utilisateur ?

Découvrir la réponse

Parce que le test unitaire interroge les propriétés calculées (getComputedStyle). Si un élément a color: red mais qu'il est recouvert par une div opaque avec un z-index supérieur, ou s'il est positionné à left: -9999px, le test unitaire verra toujours que la couleur est rouge, alors que l'utilisateur ne voit rien.

2. Comment réduire le "flakiness" des tests de régression visuelle ?

Découvrir la réponse

Plusieurs techniques existent :

• Conteneurisation : Exécuter les tests dans un Docker identique pour tous les développeurs et la CI (évite les différences d'OS).
• Masquage : Masquer les zones dynamiques (dates, noms d'utilisateurs) via CSS ou via l'API du tool de test.
• Seuils de tolérance : Configurer un threshold (seuil de différence de couleur) et un maxDiffPixels pour ignorer les micro-variations d'anti-aliasing.

3. Quand est-il contre-productif d'ajouter un test unitaire de style ?

Découvrir la réponse

Lorsque le test ne fait que répéter ce qui est écrit dans le fichier CSS sans ajouter de logique. Si vous testez expect(styles.margin).toBe('16px') pour un élément dont la seule règle est margin: 16px, vous créez une dette de maintenance sans réduire le risque de bug.

4. Quel est l'impact du VRT sur le pipeline CI/CD ?

Découvrir la réponse

Le VRT augmente significativement le temps de build et nécessite un stockage pour les images de référence. Il est recommandé de :

• Lancer les VRT en parallèle.
• Utiliser des services de cloud-visual-testing (comme Percy ou Chromatic) qui déportent le rendu et la comparaison hors du pipeline principal.

Mise en pratique

Exercice 1 : Reproduction guidée (Contrat de Design System)

Créez un test unitaire (Jest/JSDOM) qui vérifie qu'un composant Alert applique bien la couleur de fond rouge lorsque la prop type="error" est passée, et verte lorsque type="success" est passée.

Découvrir la solution commentée

// On suppose l'existence d'un composant Alert simple
import { render, screen } from '@testing-library/react';
import { Alert } from './Alert';

describe('Alert Visual Contract', () => {
  it('should have red background for error type', () => {
    render(<Alert type="error">Error message</Alert>);
    const alert = screen.getByText('Error message');
    const styles = window.getComputedStyle(alert);
    
    // On vérifie le contrat technique : la couleur doit correspondre à la palette "error"
    expect(styles.backgroundColor).toBe('rgb(255, 0, 0)'); 
  });

  it('should have green background for success type', () => {
    render(<Alert type="success">Success message</Alert>);
    const alert = screen.getByText('Success message');
    const styles = window.getComputedStyle(alert);
    
    expect(styles.backgroundColor).toBe('rgb(0, 255, 0)');
  });
});

Exercice 2 : Adaptation (Gestion du Flakiness)

Vous avez un test VRT qui échoue systématiquement à cause d'une horloge numérique affichant l'heure actuelle dans le header. Modifiez l'approche pour que le test reste stable sans supprimer l'horloge du DOM.

Découvrir la solution commentée

import { test, expect } from '@playwright/test';

test('header stability test', async ({ page }) => {
  await page.goto('/');
  
  // Solution : Masquer l'élément dynamique avant la capture
  // On injecte du CSS pour rendre l'horloge invisible ou fixe
  await page.addStyleTag({ 
    content: '.clock { visibility: hidden !important; }' 
  });

  const header = page.locator('header');
  await expect(header).toHaveScreenshot('header-baseline.png');
});

Exercice 3 : Conception (Stratégie d'Arbitrage)

On vous demande de sécuriser la refonte complète d'une bibliothèque de composants CSS (passage de CSS pur à Tailwind CSS). Le projet contient 50 composants et 20 pages. Proposez une stratégie de test détaillée en justifiant le choix entre tests unitaires et VRT pour chaque niveau.

Découvrir la solution commentée

Stratégie proposée :

1. Niveau Composants (Atomes/Molécules) → VRT Atomique (Storybook + Chromatic)

   • Justification : Le passage à Tailwind change radicalement la manière dont les classes sont écrites (on passe de .btn-primary à .bg-blue-500 .text-white). Les tests unitaires basés sur les noms de classes seraient tous à réécrire. Le VRT, lui, s'en fiche de l'implémentation : il vérifie juste que le bouton "semble" toujours identique.
   • Action : Créer un snapshot de chaque état de chaque composant avant la migration.

2. Niveau Pages (Organismes) → VRT de Pages Critiques (Playwright)

   • Justification : Tailwind peut introduire des conflits de spécificité ou des resets CSS inattendus. Capturer les 5 pages les plus visitées permet de détecter des régressions de mise en page globales.
   • Action : Captures d'écran full-page sur les navigateurs cibles (Chrome, Firefox, Safari).

3. Niveau Contrat → Tests Unitaires ciblés (Jest)

   • Justification : Certains aspects ne sont pas visuels (ex: accessibilité).
   • Action : Garder des tests unitaires pour vérifier que les attributs aria-* sont toujours présents et correctement mis à jour, car Tailwind ne gère que le style, pas la sémantique.

Résumé de l'arbitrage : 90% VRT pour la migration visuelle, 10% Tests Unitaires pour la logique et l'accessibilité.