Test de régression visuelle

Le test de régression visuelle vérifie à quoi ressemble la page plutôt que ce que contient le DOM. La première exécution capture une capture d’écran de référence (baseline) ; les exécutions suivantes prennent une nouvelle capture et la comparent pixel par pixel (ou avec un algorithme perceptuel) à cette référence. Toute différence au-delà d’un seuil fait échouer le test et produit une image de diff qui met en évidence ce qui a changé. Il détecte des problèmes que les assertions fonctionnelles ratent, comme un bouton repoussé hors de l’écran par une modification CSS.

Exemple (Playwright)

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

test('dashboard looks right', async ({ page }) => {
  await page.goto('/dashboard');
  await expect(page).toHaveScreenshot('dashboard.png', {
    fullPage: true,
    mask: [page.getByTestId('last-updated')],
    maxDiffPixels: 100,
  });
});

test('pricing card', async ({ page }) => {
  await page.goto('/pricing');
  await expect(page.getByTestId('pro-plan')).toHaveScreenshot();
});

La première exécution échoue faute de référence et en écrit une. Après un changement de design volontaire, régénérez les références avec :

npx playwright test --update-snapshots

toHaveScreenshot est une web-first assertion : elle reprend la capture jusqu’à ce que deux captures consécutives soient identiques, ce qui évite de comparer une image prise en pleine animation.

Le rendre stable

• Même environnement pour les références et les exécutions. Les polices et l’anticrénelage diffèrent selon les systèmes d’exploitation, c’est pourquoi Playwright stocke les références par navigateur et par plateforme. Générez-les dans la même image Docker que celle de la CI.
• Masquez le contenu dynamique. Horodatages, avatars, publicités et graphiques alimentés en direct seront toujours différents.
• Figez le temps et les données. Utilisez des données de test fixes et, si nécessaire, une horloge simulée.
• Désactivez les animations. Playwright désactive par défaut les animations CSS pour les captures.
• Préférez les composants aux pages entières. La capture d’une carte échoue pour une raison ; une page entière, pour vingt.

Erreurs fréquentes

• Approuver les diffs sans les regarder. Mettre à jour les références en masse transforme la suite en simple tampon d’approbation.
• Tolérance zéro partout. De minuscules différences de rendu créent du bruit. Fixez un petit seuil, mais pas au point de masquer de vraies régressions.
• L’utiliser à la place des tests fonctionnels. Une capture peut montrer que le total est au bon endroit, pas qu’il s’agit du bon montant.