MohandOussadi
Retour au blog
Tests end-to-end avec Playwright : une stratégie qui tient dans la durée

Tests end-to-end avec Playwright : une stratégie qui tient dans la durée

17 mars 2026
3 min de lecture
Tests
Playwright
Qualité

Les tests end-to-end ont mauvaise réputation : lents, instables, cassés à chaque changement d'interface. Pourtant, ce sont les seuls à vérifier ce qui compte vraiment : qu'un utilisateur peut s'inscrire, acheter, réserver. Avec Playwright et quelques règles, on obtient une suite fiable qui rassure au lieu de ralentir.

Quoi tester en end-to-end ?

Les tests E2E sont les plus coûteux à écrire et à exécuter. Ils forment le sommet de la pyramide des tests : peu nombreux, ils couvrent les parcours critiques, tandis que la logique détaillée est testée plus bas, en tests unitaires et d'intégration.

La pyramide des tests : beaucoup de tests unitaires, moins de tests d'intégration, quelques tests end-to-end
La pyramide des tests : beaucoup de tests unitaires, moins de tests d'intégration, quelques tests end-to-end

Une bonne question pour choisir : « Si ce parcours casse en production, est-ce qu'on perd de l'argent ou des utilisateurs ? » Inscription, connexion, paiement, réservation, formulaire de contact : oui. La couleur d'un bouton : non.

Des sélecteurs qui ne cassent pas

La première cause d'instabilité, ce sont les sélecteurs CSS fragiles (.btn-primary > span:nth-child(2)). Playwright encourage les locators orientés utilisateur, qui ciblent les éléments comme un humain (ou un lecteur d'écran) les perçoit.

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

test("un visiteur peut réserver une séance", async ({ page }) => {
  await page.goto("/reserver");

  await page.getByRole("button", { name: "Choisir un créneau" }).click();
  await page.getByRole("option", { name: /10:00/ }).click();
  await page.getByLabel("Adresse e-mail").fill("test@example.com");
  await page.getByRole("button", { name: "Confirmer" }).click();

  await expect(page.getByRole("heading", { name: "Réservation confirmée" })).toBeVisible();
});

Bonus : si getByRole ou getByLabel ne trouve pas un élément, c'est souvent le signe d'un problème d'accessibilité. Les tests améliorent l'application au passage.

Ne jamais attendre « à l'aveugle »

  • Pas de `waitForTimeout(2000)` : c'est lent quand tout va bien et insuffisant quand le serveur est chargé.
  • Les actions attendent automatiquement que l'élément soit visible, stable et activable.
  • Les assertions web-first (await expect(locator).toBeVisible(), toHaveText, toHaveURL) réessaient jusqu'à ce que la condition soit vraie ou que le délai expire.

L'authentification une seule fois

Se connecter via l'interface dans chaque test fait perdre des minutes. Playwright permet de se connecter une fois dans un projet de configuration, de sauvegarder l'état (cookies, stockage local) et de le réutiliser dans tous les tests.

// playwright.config.ts
export default defineConfig({
  projects: [
    { name: "setup", testMatch: /auth\.setup\.ts/ },
    {
      name: "chromium",
      use: { ...devices["Desktop Chrome"], storageState: "playwright/.auth/user.json" },
      dependencies: ["setup"],
    },
  ],
  use: { trace: "on-first-retry" },
  retries: process.env.CI ? 2 : 0,
});

Des données de test maîtrisées

  • Chaque test crée ses propres données (via l'API ou la base), plutôt que de dépendre d'un jeu de données partagé que d'autres tests modifient.
  • Des identifiants uniques (test-${Date.now()}@example.com) permettent l'exécution en parallèle.
  • Les services externes (paiement, e-mail) sont simulés avec page.route() ou remplacés par leurs environnements de test.

Déboguer avec les traces

Avec trace: "on-first-retry", Playwright enregistre une trace complète quand un test échoue puis est relancé : chaque action, une capture du DOM avant et après, les requêtes réseau et la console. npx playwright show-trace permet de rejouer l'échec pas à pas. C'est l'outil qui change le plus la vie quand un test échoue uniquement en CI.

En CI

  • Tester le build de production, avec webServer dans la configuration pour démarrer l'application automatiquement.
  • Répartir les tests sur plusieurs machines avec --shard=1/4.
  • Suivre les tests instables : un test qui ne passe qu'au deuxième essai doit être corrigé, pas ignoré.

Conclusion

Une suite E2E utile est courte, ciblée sur les parcours qui comptent, écrite avec des locators accessibles, sans attentes arbitraires, avec des données isolées et des traces pour déboguer. Avec ces règles, les tests Playwright deviennent le filet de sécurité qui permet de livrer sereinement.

Partager cet article