Test-Sharding

Sharding teilt eine Suite in N ungefähr gleich große Teile und führt jeden Teil als eigenen Job aus, meist auf getrennten CI-Maschinen. Es liegt eine Ebene über parallelen Workern: Worker führen Tests nebenläufig innerhalb einer Maschine aus, Shards verteilen die Suite auf mehrere Maschinen. Durch die Kombination von beidem bleiben große UI-Suites innerhalb einer vernünftigen Pipeline-Laufzeit.

Beispiel (Playwright und GitHub Actions)

Playwright unterstützt Sharding mit einem einzigen Flag:

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

In der CI startet eine Matrix einen Job pro Shard. Jeder Shard schreibt einen Blob-Report, und ein abschließender Job führt sie zu einem HTML-Report zusammen:

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

Der Merge-Job lädt jedes blob-report-*-Artefakt in einen Ordner herunter und führt npx playwright merge-reports --reporter html ./all-blob-reports aus.

Wie Tests verteilt werden

Playwright teilt nach Testdateien auf, sofern nicht fullyParallel: true gesetzt ist; dann verteilt es einzelne Tests gleichmäßig auf die Shards. Bei der Aufteilung nach Dateien kann eine einzige riesige Spec-Datei einen Shard deutlich langsamer machen als die anderen, halten Sie Dateien daher angemessen klein.

Häufige Fehler

• Eine nicht isolierte Suite sharden. Tests, die Daten teilen oder von der Reihenfolge abhängen, bestehen auf einer Maschine und schlagen fehl, sobald sie aufgeteilt werden. Beheben Sie zuerst die Isolation.
• Das Gesamtergebnis verlieren. Ohne einen Merge-Schritt sind Fehlschläge über N Job-Logs und N Reports verstreut.
• Zu viele Shards. Jeder Shard zahlt die Fixkosten für Checkout, Installation und Browser-Download. Ab einem gewissen Punkt erhöhen weitere Shards die Kosten, ohne Zeit zu sparen.
• fail-fast bleibt aktiv. Ein fehlschlagender Shard bricht die anderen ab, und Sie verlieren die restlichen Ergebnisse.