Playbook Playwright
| Statut | Actif — v1.0 — 2026-06-27 |
| Priorité | P1 |
| Obligatoire V1 | Non |
| Responsable | Sylvain |
| Voir aussi | Playbook Testing · Template Playwright |
Philosophie
On ne vise pas 100 % de couverture.
Les tests E2E sont coûteux à écrire et à maintenir. Un test fragile est pire que pas de test : il génère du bruit, ralentit la CI, et finit par être ignoré.
Règle DMV : tester uniquement les parcours critiques — ceux dont la rupture empêche un utilisateur d'utiliser l'application.
Parcours critiques (obligatoires)
Ces tests doivent exister dans tout projet frontend en production :
- Ouverture de l'application — la page principale se charge sans erreur
- Connexion utilisateur — le formulaire de login fonctionne
- Navigation principale — les liens du menu naviguent vers les bonnes pages
Parcours métier (selon le projet)
| Projet | Parcours à couvrir |
|---|---|
| dmv-public | Ouverture mur, navigation rubriques, agenda, recherche |
| dmv-workspace | Connexion, création publication, création acteur |
| backoffice | Connexion admin, création mairie, gestion utilisateurs |
Ce qu'on ne teste PAS avec Playwright
- La logique métier (→ tests unitaires ou d'intégration)
- Les cas d'erreur de formulaires (→ tests d'intégration)
- L'apparence visuelle exacte (trop fragile)
- Les fonctionnalités secondaires qui ne bloquent pas l'usage
Structure
tests/e2e/
auth.spec.ts — connexion, déconnexion
navigation.spec.ts — menu, liens, redirections
mur.spec.ts — parcours mur de la ville
agenda.spec.ts — consultation agenda
recherche.spec.ts — recherche
Un fichier = un domaine fonctionnel. Pas plus de 5-8 tests par fichier.
Convention d'écriture
test('affiche la page d\'accueil', async ({ page }) => {
await page.goto('/');
await expect(page).toHaveTitle(/DMV/);
await expect(page.getByRole('main')).toBeVisible();
});
test('permet la connexion', async ({ page }) => {
await page.goto('/connexion');
await page.fill('[name=email]', 'test@example.com');
await page.fill('[name=password]', 'password');
await page.click('[type=submit]');
await expect(page).toHaveURL('/espace');
});
Règles :
- Noms de tests en français, descriptifs ("affiche X", "permet Y")
- Sélecteurs par rôle ou attribut sémantique (
getByRole,getByLabel) - Pas de
waitForTimeout— utiliser les auto-wait Playwright - Un test = un scénario utilisateur complet
Configuration
// playwright.config.ts
import { defineConfig } from '@playwright/test';
export default defineConfig({
testDir: './tests/e2e',
timeout: 30_000,
retries: process.env.CI ? 1 : 0,
use: {
baseURL: process.env.PLAYWRIGHT_BASE_URL || 'http://localhost:3000',
trace: 'on-first-retry',
screenshot: 'only-on-failure',
},
projects: [
{ name: 'chromium', use: { browserName: 'chromium' } },
],
});
Un seul browser en CI (Chromium). Multi-browser uniquement si besoin explicite de compatibilité.
Maintenance
Quand un test casse
- Est-ce un vrai bug ou un test fragile ?
- Si bug : corriger le code, le test reste
- Si test fragile : corriger le sélecteur ou la stratégie d'attente
- Ne jamais commenter ou supprimer sans comprendre l'échec
Quand le produit évolue
Un test qui casse parce que l'UI a changé intentionnellement → mettre à jour le test dans la même PR que le changement UI.
Revue périodique
À chaque sprint :
- Tests qui flakent régulièrement en CI → corriger
- Tests de fonctionnalités supprimées → supprimer
- Parcours critiques non couverts → planifier
Variables d'environnement
PLAYWRIGHT_BASE_URL=https://staging.monvillage.fr
TEST_USER_EMAIL=test@dmv.fr
TEST_USER_PASSWORD=...
Définies dans les secrets GitHub pour la CI.
CI
Le workflow Playwright tourne sur les PRs qui modifient des fichiers frontend. Il ne bloque pas le merge par défaut sur les nouveaux projets — à promouvoir en required check une fois la suite est stable (zéro flake sur 10 runs).
Voir Template Playwright.