# Migrer ses tests end-to-end WordPress de Puppeteer vers Playwright

> Playwright gagne du terrain sur Puppeteer pour les tests E2E, avec de meilleurs outils de débogage et un support multi-navigateur natif. Retour sur notre migration d'une suite WordPress existante.

- Auteur : Clément Hadrot
- Publié le : 2022-11-16
- Mis à jour le : 2022-11-16
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/migration-puppeteer-playwright-wordpress/

## L’essentiel

- Un mode trace qui rejoue visuellement chaque échec de test
- Le support natif de Firefox et WebKit, pas seulement Chromium
- Une API auto-attente qui élimine une partie des attentes manuelles

Notre suite de tests E2E WordPress tournait sous Puppeteer depuis plus d'un an, avec le paquet officiel `@wordpress/e2e-test-utils` décrit dans un précédent article. Le système fonctionnait, mais deux frustrations revenaient régulièrement : des échecs difficiles à diagnostiquer sans rejouer manuellement le scénario, et l'impossibilité de vérifier facilement le comportement d'un site sur un moteur autre que Chromium. [Playwright](https://playwright.dev/), développé par Microsoft, répond aux deux problèmes, et l'équipe cœur de WordPress elle-même a commencé à l'adopter pour ses propres tests E2E via le paquet `@wordpress/e2e-test-utils-playwright`.

Cet article détaille notre migration d'une suite existante, les gains concrets observés, et les points d'attention pour une équipe qui envisage le même chemin.

## Pourquoi migrer : les limites rencontrées avec Puppeteer

Puppeteer ne pilote nativement que Chromium (avec un support expérimental de Firefox à cette période). Pour un client dont une part significative du trafic vient de Safari sur mobile, cette limite empêchait de détecter des bugs spécifiques à WebKit avant qu'ils n'atteignent la production. Par ailleurs, le débogage d'un test qui échoue de façon intermittente en CI reposait essentiellement sur des captures d'écran ponctuelles, ce qui laissait beaucoup de zones d'ombre sur ce qui s'était réellement passé entre deux étapes du test.

## Ce que Playwright apporte concrètement

Playwright pilote nativement Chromium, Firefox et WebKit avec la même API, ce qui permet d'exécuter la même suite de tests sur les trois moteurs sans code spécifique. Sa fonctionnalité de *trace* enregistre, pour chaque test, un journal détaillé rejouable visuellement : capture DOM à chaque étape, requêtes réseau, console, et timeline précise des actions effectuées.

```
npx playwright show-trace trace.zip
```

Cette commande ouvre une interface qui permet de naviguer étape par étape dans l'exécution d'un test échoué, bien plus rapide à exploiter qu'une capture d'écran isolée pour comprendre ce qui a réellement dérapé.

> L'essentiel à retenir : Un mode trace qui rejoue visuellement chaque échec de test ; Le support natif de Firefox et WebKit, pas seulement Chromium ; Une API auto-attente qui élimine une partie des attentes manuelles

## Installer Playwright et le paquet WordPress

```
npm install --save-dev @playwright/test @wordpress/e2e-test-utils-playwright
npx playwright install
```

La dernière commande télécharge les navigateurs nécessaires (Chromium, Firefox, WebKit), gérés directement par Playwright plutôt que par le système. Le fichier de configuration `playwright.config.js` remplace le `jest.config.js` utilisé côté Puppeteer :

```
module.exports = {
    testDir: './tests/e2e',
    use: {
        baseURL: process.env.WP_BASE_URL || 'http://localhost:8889',
        trace: 'on-first-retry',
    },
    projects: [
        { name: 'chromium', use: { browserName: 'chromium' } },
    ],
};
```

## Réécrire un test existant

Voici le même test décrit dans un précédent article, insertion d'un bloc personnalisé puis vérification du rendu, réécrit avec Playwright et son paquet dédié WordPress :

```
const { test, expect } = require( '@wordpress/e2e-test-utils-playwright' );

test( 'insère le bloc, publie l\'article et affiche le rendu sur le front', async ( { admin, editor, page } ) => {
    await admin.createNewPost();
    await editor.insertBlock( { name: 'mon-plugin/citation-mise-en-avant' } );

    await page.keyboard.type( 'Un test qui échoue en silence n\'aide personne.' );

    await editor.publishPost();
    const url = await page.evaluate( () => window.location.href );

    await page.goto( url );

    const contenu = page.locator( '.wp-block-mon-plugin-citation-mise-en-avant' );
    await expect( contenu ).toContainText( 'Un test qui échoue en silence' );
} );
```

La différence la plus marquante à l'usage : les `locator` de Playwright intègrent une logique d'attente automatique. Plus besoin d'ajouter manuellement des `waitForSelector` avant chaque interaction, comme c'était souvent nécessaire avec Puppeteer pour fiabiliser un test.

## Ce qui a changé dans nos chiffres

Sur notre suite de trente-deux tests E2E migrée intégralement, le temps d'exécution total en CI est passé d'environ dix-huit minutes à un peu moins de onze minutes, principalement grâce à la parallélisation native de Playwright, plus simple à configurer que l'équivalent avec Jest et jest-puppeteer. Le nombre d'échecs intermittents non reproductibles a également nettement diminué, ce que nous attribuons à la fois à l'auto-attente et à la stabilité générale du moteur de test.

| Indicateur | Avant (Puppeteer) | Après (Playwright) |
| --- | --- | --- |
| Temps total en CI | ~18 minutes | ~11 minutes |
| Navigateurs testés | Chromium uniquement | Chromium, Firefox, WebKit disponibles |
| Diagnostic d'un échec | Captures d'écran ponctuelles | Trace rejouable complète |

> Sur ce projet, la migration nous a pris environ une semaine, tests inclus. Le gain de temps n'était pas l'objectif initial : ce sont les traces rejouables qui ont justifié la migration à elles seules, en divisant par un facteur important le temps passé à diagnostiquer un échec en CI.

## En résumé

Playwright, associé au paquet officiel `@wordpress/e2e-test-utils-playwright`, apporte un confort de débogage et une couverture multi-navigateur que Puppeteer ne proposait pas nativement sur nos projets. La migration d'une suite existante reste un chantier raisonnable, surtout si les tests s'appuyaient déjà sur les utilitaires officiels WordPress, dont les équivalents Playwright suivent une API très proche. Pour une nouvelle suite E2E démarrée aujourd'hui, Playwright est clairement notre recommandation par défaut.