Sharding des tests

Le sharding divise une suite en N parties à peu près égales et exécute chaque partie comme un job séparé, généralement sur des machines de CI distinctes. C’est un niveau au-dessus des workers parallèles : les workers exécutent des tests en parallèle sur une seule machine, tandis que les shards répartissent la suite sur plusieurs machines. Combiner les deux permet aux grosses suites d’interface de tenir dans une durée de pipeline raisonnable.

Exemple (Playwright et GitHub Actions)

Playwright prend en charge le sharding avec une seule option :

npx playwright test --shard=1/4
npx playwright test --shard=2/4

En CI, une matrice démarre un job par shard. Chaque shard produit un rapport blob, et un job final les fusionne en un seul rapport HTML :

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

Le job de fusion télécharge chaque artefact blob-report-* dans un même dossier et exécute npx playwright merge-reports --reporter html ./all-blob-reports.

Comment les tests sont répartis

Playwright découpe par fichier de test, sauf si fullyParallel: true est défini, auquel cas il répartit les tests individuels entre les shards. Avec un découpage par fichier, un énorme fichier de spec peut rendre un shard bien plus lent que les autres : gardez donc des fichiers de taille raisonnable.

Erreurs fréquentes

• Sharder une suite qui n’est pas isolée. Des tests qui partagent des données ou dépendent de l’ordre passent sur une machine et échouent une fois répartis. Corrigez d’abord l’isolation.
• Perdre le résultat global. Sans étape de fusion, les échecs sont éparpillés dans N logs de jobs et N rapports.
• Trop de shards. Chaque shard paie le coût fixe du checkout, de l’installation et du téléchargement des navigateurs. Au-delà d’un certain point, ajouter des shards coûte plus cher sans faire gagner de temps.
• Laisser fail-fast activé. Un shard en échec annule les autres, et vous perdez le reste des résultats.