5 min de lecture - Playwright : une automatisation des tests QA enfin fiable

Playwright peut faciliter l'écriture et le diagnostic des tests navigateur, mais aucun framework ne supprime les tests instables. Une automatisation fiable exige toujours des données stables, des assertions explicites, des dépendances maîtrisées et des preuves d'échec utiles.

Playwright Test prend en charge Chromium, Firefox et WebKit. Il réunit un test runner, des assertions, l'isolation des navigateurs, l'exécution parallèle et des outils de diagnostic. L'auto-wait traite des contrôles d'actionnabilité définis, mais ne corrige ni les données instables, ni les dépendances tierces, ni une assertion erronée. Les workers CI ont aussi besoin des binaires navigateur et des dépendances système correspondants.

Ce qui distingue Playwright

Playwright est une bibliothèque open source d'automatisation de navigateur qui prend en charge Chromium, Firefox et WebKit via une seule API. Les projets permettent d'exécuter un même scénario sur plusieurs navigateurs, appareils ou environnements configurés.

Choisissez un framework selon les scénarios, les langages, la couverture navigateur et le modèle d'exploitation nécessaires. Les tableaux comparatifs vieillissent vite ; cet article ne classe donc pas Playwright, Cypress et Selenium selon des fonctions qui changent entre les versions.

Les auto-waits réduisent les attentes arbitraires

Avant les actions prises en charge, Playwright vérifie les conditions pertinentes pour l'action. Pour un clic, la documentation cite notamment une correspondance unique, la visibilité, la stabilité, l'état activé et la réception des événements.

• Attaché au DOM
• Visible
• Stable (sans animation en cours)
• Activé
• Prêt à recevoir des événements

Ces contrôles réduisent le besoin de temporisations arbitraires. Ils ne suppriment pas toutes les attentes ni tous les échecs : un état métier asynchrone, un job en arrière-plan ou un système externe peut encore exiger une condition observable et un timeout volontaire.

// Playwright auto-waits for the button to be clickable
await page.getByRole('button', { name: 'Submit' }).click()

// No need for explicit waits, Playwright handles it
await expect(page.getByText('Order confirmed')).toBeVisible()

Contextes de navigateur : l'isolation sans surcoût

Playwright introduit les contextes de navigateur, des sessions de navigateur légères et isolées qui partagent un seul processus de navigateur. Chaque contexte dispose de ses propres cookies, de son propre stockage et de son propre cache :

// Create isolated contexts for parallel testing
const context1 = await browser.newContext()
const context2 = await browser.newContext()

// Each context is completely isolated
const adminPage = await context1.newPage()
const userPage = await context2.newPage()

Cela permet de tester des scénarios multi-utilisateurs (administrateur vs utilisateur standard) et d'exécuter des tests en parallèle sans le surcoût de lancer des instances de navigateur distinctes.

Prise en main

Installation et premier test

npm init playwright@latest

Cette commande génère un projet avec la configuration, des exemples de tests et des fichiers de workflow CI. Voici un test minimal :

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

test('user can log in', async ({ page }) => {
  await page.goto('/login')
  await page.getByLabel('Email').fill('[email protected]')
  await page.getByLabel('Password').fill('password123')
  await page.getByRole('button', { name: 'Sign in' }).click()

  await expect(page.getByText('Welcome back')).toBeVisible()
})

Codegen : enregistrer des tests visuellement

L'outil codegen de Playwright enregistre les interactions dans le navigateur et génère le code de test correspondant :

npx playwright codegen https://your-app.com

Cela ouvre un navigateur avec une barre d'outils d'enregistrement. Naviguez dans votre application, et Playwright génère le code de test correspondant, avec les bons locators et les bonnes assertions.

Trace viewer : déboguer visuellement les échecs

Lorsqu'un test échoue, le trace viewer propose une relecture étape par étape avec captures d'écran, snapshots du DOM, journaux réseau et sorties console :

npx playwright show-trace trace.zip

La trace peut aider à repérer le moment où l'exécution observée s'écarte du comportement attendu. Son utilité dépend du moment où elle est activée et des éléments que le test capture.

Interception réseau

Playwright peut intercepter et modifier les requêtes HTTP, ce qui ouvre la voie à des scénarios de test puissants :

// Mock an API response
await page.route('/api/users', async (route) => {
  await route.fulfill({
    status: 200,
    body: JSON.stringify([{ id: 1, name: 'Test User' }]),
  })
})

// Simulate an error
await page.route('/api/orders', async (route) => {
  await route.fulfill({ status: 500, body: 'Internal Server Error' })
})

// Simulate slow network
await page.route('**/*', async (route) => {
  await new Promise((resolve) => setTimeout(resolve, 3000))
  await route.continue()
})

L'interception peut isoler certains scénarios frontend et exercer des états d'erreur ou de chargement. Conservez une couverture end-to-end distincte contre un vrai backend : une réponse simulée ne vérifie pas l'intégration qu'elle remplace.

Intégration CI/CD

GitHub Actions

name: E2E Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

Exécution parallèle

Playwright exécute les tests en parallèle par défaut, à l'aide de processus worker. Ajustez le niveau de parallélisme en fonction des ressources de votre CI :

// playwright.config.ts
export default defineConfig({
  workers: process.env.CI ? 4 : undefined,
  retries: process.env.CI ? 2 : 0,
  reporter: process.env.CI ? 'html' : 'list',
})

Mesurez le nombre de workers sur votre propre matériel CI. Des workers supplémentaires peuvent raccourcir la suite, mais aussi révéler des problèmes d'isolation ou surcharger des dépendances partagées.

Comment comparer Playwright à un autre framework

Construisez une courte preuve sur la même application et le même runner CI. Notez les outils selon les navigateurs cibles, les langages, l'isolation, les preuves de diagnostic, le temps d'exécution, l'accessibilité et l'effort nécessaire pour maintenir un scénario instable. Vérifiez la documentation actuelle de chaque projet avant de décider.

L'expertise et l'infrastructure existantes comptent. Une migration ne se justifie pas par une liste de fonctions ; elle doit résoudre un problème de test ou d'exploitation mesuré.

Des tests end-to-end fiables et maintenables

Playwright fournit des primitives utiles pour les tests multi-navigateurs, l'isolation, les traces et l'exécution parallèle. L'équipe reste responsable des données, assertions, dépendances et revues d'échec. Commencez par un parcours critique, exécutez-le plusieurs fois en CI et n'élargissez la suite que lorsque ses échecs sont compréhensibles. Besoin d'aide pour structurer votre stratégie d'automatisation QA ? Discutons-en.

Sources consultées

• installation de Playwright et navigateurs pris en charge, consultée le 27 août 2026
• actionnabilité et auto-waiting de Playwright, consultés le 27 août 2026
• installation des navigateurs Playwright, consultée le 27 août 2026
• exécution parallèle de Playwright, consultée le 27 août 2026