# Sharder vos tests Playwright sur plusieurs machines pour diviser le temps CI

> Une suite E2E Playwright qui dépasse vingt minutes en intégration continue décourage les développeurs de la lancer. Voici comment la répartir sur plusieurs machines en parallèle.

- Auteur : Clément Hadrot
- Publié le : 2025-04-21
- Mis à jour le : 2025-04-21
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/sharder-tests-playwright-plusieurs-machines/

## L’essentiel

- Répartir les fichiers de test en lots équilibrés, pas seulement en nombre égal
- Fusionner les rapports de chaque lot en un seul résultat lisible
- Surveiller que cette répartition ne masque pas une dépendance cachée entre tests

`npx playwright test --shard=1/4` : cette seule option, ajoutée à une commande déjà connue, suffit à transformer une exécution séquentielle de vingt-deux minutes en quatre exécutions parallèles de moins de six minutes chacune. C'est le résultat obtenu sur la suite de tests de bout en bout d'une plateforme de billetterie, dont le tunnel d'achat, la gestion des places et le paiement représentaient à eux seuls plus de cent-vingt scénarios Playwright.

Cette technique, qui consiste à répartir une suite en plusieurs lots exécutés sur des machines distinctes, résout un problème réel : au-delà d'une certaine durée, les développeurs cessent de lancer la suite complète en local et se contentent d'attendre le retour de la pipeline, ce qui retarde la détection des régressions.

## Comprendre comment Playwright répartit les fichiers

Playwright répartit les fichiers de test, pas les cas individuels à l'intérieur d'un même fichier. L'option `--shard=N/M` indique à l'exécution en cours qu'elle doit traiter le lot numéro N sur un total de M lots, Playwright se chargeant lui-même de répartir les fichiers de façon équilibrée selon son propre algorithme de partitionnement :

```
# Machine 1
npx playwright test --shard=1/4

# Machine 2
npx playwright test --shard=2/4

# Machine 3
npx playwright test --shard=3/4

# Machine 4
npx playwright test --shard=4/4
```

### Configurer la matrice dans GitHub Actions

Dans une pipeline GitHub Actions, une matrice de jobs permet de lancer les quatre lots en parallèle sans dupliquer la configuration :

```
jobs:
  e2e:
    strategy:
      matrix:
        shard: [1, 2, 3, 4]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --shard=${{ matrix.shard }}/4
      - uses: actions/upload-artifact@v4
        with:
          name: rapport-shard-${{ matrix.shard }}
          path: blob-report
```

## Fusionner les rapports en un seul résultat lisible

Quatre lots exécutés en parallèle produisent quatre rapports distincts. Sans fusion, une équipe doit consulter quatre pages différentes pour savoir si la suite complète est passée, ce qui annule une partie du bénéfice obtenu. Playwright propose un mécanisme de fusion dédié à partir des rapports au format *blob* générés par chaque lot :

```
npx playwright merge-reports --reporter=html ./tous-les-rapports
```

Un job supplémentaire, déclenché uniquement après que les quatre lots ont terminé, télécharge chaque rapport intermédiaire et produit ce rapport fusionné, publié comme artefact unique de la pipeline.

> L'essentiel à retenir : Répartir les fichiers de test en lots équilibrés, pas seulement en nombre égal ; Fusionner les rapports de chaque lot en un seul résultat lisible ; Surveiller que cette répartition ne masque pas une dépendance cachée entre tests

## Le piège d'une dépendance cachée entre tests

Cette répartition en lots révèle parfois des dépendances entre tests restées invisibles tant que la suite s'exécutait sur une seule machine dans un ordre stable. Un test qui suppose qu'un compte utilisateur créé par un test précédent existe encore échoue de façon imprévisible dès qu'il se retrouve dans un lot différent de celui qui créait ce compte. Ce type d'échec, difficile à reproduire localement, doit alerter immédiatement sur un manque d'isolation plutôt que sur un problème de répartition lui-même.

- Chaque test doit créer ses propres données via une fixture dédiée, jamais réutiliser un état laissé par un autre test.
- Les hooks `beforeAll` partagés entre plusieurs fichiers d'un même lot sont à surveiller particulièrement.
- Un test qui échoue uniquement dans certaines répartitions et jamais dans d'autres est le signal le plus fiable d'une dépendance cachée.

## Équilibrer les lots au-delà du simple découpage automatique

Le partitionnement par défaut de Playwright répartit les fichiers pour équilibrer approximativement leur nombre, mais un fichier contenant trente scénarios courts et un autre n'en contenant que deux très longs peuvent produire des lots déséquilibrés en durée réelle malgré un nombre de fichiers identique. Un fichier de statistiques d'exécution, conservé d'une exécution à l'autre, permet d'ajuster manuellement la répartition si un déséquilibre récurrent apparaît.

> Diviser le nombre de machines par deux ne divise jamais exactement le temps par deux : la coordination et le démarrage de chaque environnement ont un coût fixe qui s'ajoute à chaque lot.

## En résumé

Cette répartition en lots sous Playwright transforme une suite de bout en bout dissuasive en une suite dont le retour tient dans une pause café plutôt que dans une pause déjeuner. La configuration technique reste simple, à condition de fusionner correctement les rapports et de traiter tout échec inconsistant entre lots comme un signal d'isolation défaillante plutôt que comme un simple aléa de répartition.