テストシャーディング（Test Sharding）

シャーディングは、スイートを N 個のほぼ均等な部分に分け、それぞれを別のジョブとして、通常は別々の CI マシンで実行します。並列ワーカーより 1 つ上のレベルの仕組みです。ワーカーは 1 台のマシン内でテストを並行実行し、シャードはスイートを複数のマシンに分散させます。大規模な UI スイートのパイプライン時間を妥当な範囲に収めるには、この 2 つを組み合わせます。

例（Playwright と GitHub Actions）

Playwright はフラグ 1 つでシャーディングに対応しています。

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

CI ではマトリクスを使い、シャードごとに 1 つのジョブを起動します。各シャードが blob レポートを書き出し、最後のジョブがそれらを 1 つの 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

マージ用のジョブは、すべての blob-report-* アーティファクトを 1 つのフォルダーにダウンロードし、npx playwright merge-reports --reporter html ./all-blob-reports を実行します。

テストの振り分け方

Playwright は、fullyParallel: true が設定されていない限りテストファイル単位で分割します。設定されている場合は、個々のテストをシャード間で均等に振り分けます。ファイル単位で分割する場合、巨大なスペックファイルが 1 つあると 1 つのシャードだけがほかよりずっと遅くなるため、ファイルは適度に小さく保ちましょう。

よくある間違い

• 独立していないスイートをシャーディングする。 データを共有していたり順序に依存していたりするテストは、1 台のマシンでは合格しても、分割すると失敗します。まず独立性を確保しましょう。
• 全体の結果を見失う。 マージの手順がないと、失敗が N 個のジョブログと N 個のレポートに散らばってしまいます。
• シャードが多すぎる。 各シャードは、チェックアウト、インストール、ブラウザーのダウンロードという固定コストを毎回支払います。ある点を超えると、シャードを増やしても時間は短縮されず、コストだけが増えます。
• fail-fast を有効のままにする。 1 つのシャードが失敗するとほかのシャードがキャンセルされ、残りの結果が失われます。