Playwright et CI/CD : faire tourner ses tests a chaque commit

C'est l'etape que les QA manuels sautent le plus souvent en autodidacte, et c'est justement celle que les recruteurs verifient. Une formation Playwright complete se termine toujours par la CI/CD : sans execution automatique, tes tests sont un document Word un peu sophistique.

Ce que la CI change concretement

1. Rendre la suite executable ailleurs que chez toi

Avant de toucher au pipeline, trois prerequis :

• URL configurable : jamais d'URL en dur dans les tests.

// playwright.config.ts
export default defineConfig({
  use: { baseURL: process.env.BASE_URL ?? 'http://localhost:3000' },
  retries: process.env.CI ? 2 : 0,
  reporter: process.env.CI ? [['html'], ['github']] : [['list']],
});

• Donnees de test creees par les tests eux-memes, via l'API plutot que via l'UI. Voir automatiser vos tests API avec Playwright.
• Aucune dependance entre tests : l'ordre d'execution en CI n'est pas celui de ton poste.

2. Un pipeline minimal

Le principe est identique sur GitHub Actions, GitLab CI ou Jenkins : installer les dependances, installer les navigateurs, lancer les tests, publier le rapport.

- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test
- uses: actions/upload-artifact@v4
  if: always()
  with:
    name: playwright-report
    path: playwright-report/

Le if: always() est essentiel : c'est quand les tests echouent que tu as besoin du rapport.

L'implementation detaillee est ici : integrer Playwright dans votre pipeline CI/CD avec GitHub Actions.

3. Reduire le temps d'execution

Une suite qui prend 40 minutes ne sera pas respectee par l'equipe. Trois leviers, par ordre d'efficacite :

1. Parallelisation : workers et sharding (--shard=1/4) sur plusieurs machines.
2. Pyramide de tests : deplacer les verifications metier vers des tests API rapides et garder l'UI pour les parcours critiques.
3. Etat partage : reutiliser un storageState d'authentification au lieu de se reconnecter dans chaque test.

// auth.setup.ts : connexion une seule fois
await page.context().storageState({ path: 'playwright/.auth/user.json' });

4. Traiter le flakiness comme un bug

Les retries en CI servent a absorber l'aleatoire reseau, pas a masquer un test mal ecrit. Bonne pratique :

• activer trace: 'on-first-retry' pour analyser les echecs
• suivre les tests qui passent seulement au retry
• corriger ou supprimer, jamais ignorer indefiniment

5. Quand declencher quoi

Cette segmentation garde des retours rapides sans perdre de couverture.

6. Ce que tu peux montrer en entretien

Une capture de pipeline vert avec un rapport HTML vaut plus que n'importe quelle certification. Prepare trois elements :

• le lien du repo avec le fichier de pipeline
• le temps d'execution avant / apres optimisation
• un exemple concret de regression detectee automatiquement

Pour aller plus loin

Cette etape suppose des bases solides : TypeScript, premiers tests et structure avec le Page Object Model. L'ordre complet est detaille dans le plan de formation Playwright en 12 semaines.

Tu veux mettre en place ce pipeline sur un projet reel, avec quelqu'un qui relit ton code ? Le programme est presente sur la page d'accueil.