테스트 샤딩

샤딩은 스위트를 대략 같은 크기의 N개 부분으로 나누고, 각 부분을 별도 잡(job)으로, 보통은 별도 CI 머신에서 실행하는 방식입니다. 병렬 워커보다 한 단계 위의 개념입니다. 워커는 한 머신 안에서 테스트를 동시에 실행하고, 샤드는 스위트를 여러 머신에 분산합니다. 대규모 UI 스위트가 적당한 파이프라인 시간 안에 끝나려면 두 방식을 함께 써야 합니다.

예시 (Playwright와 GitHub Actions)

Playwright는 플래그 하나로 샤딩을 지원합니다.

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

CI에서는 매트릭스가 샤드마다 잡을 하나씩 시작합니다. 각 샤드는 blob 리포트를 쓰고, 마지막 잡이 이를 하나의 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-* 아티팩트를 한 폴더에 내려받은 뒤 npx playwright merge-reports --reporter html ./all-blob-reports를 실행합니다.

테스트가 분배되는 방식

Playwright는 fullyParallel: true가 설정되지 않은 한 테스트 파일 단위로 나눕니다. 설정된 경우에는 개별 테스트 단위로 샤드 간 균형을 맞춥니다. 파일 단위로 나눌 때는 거대한 spec 파일 하나 때문에 특정 샤드만 훨씬 느려질 수 있으므로, 파일 크기를 적당히 작게 유지하십시오.

흔한 실수

• 격리되지 않은 스위트를 샤딩하는 것. 데이터를 공유하거나 실행 순서에 의존하는 테스트는 한 머신에서는 통과하지만 나누면 실패합니다. 테스트 격리부터 해결하십시오.
• 전체 결과를 잃어버리는 것. 병합 단계가 없으면 실패 내역이 N개의 잡 로그와 N개의 리포트에 흩어집니다.
• 샤드가 너무 많은 것. 샤드마다 체크아웃, 설치, 브라우저 다운로드라는 고정 비용이 듭니다. 일정 수준을 넘으면 샤드를 늘려도 시간은 줄지 않고 비용만 늘어납니다.
• fail-fast를 켜 둔 것. 샤드 하나가 실패하면 나머지가 취소되어 남은 결과를 얻지 못합니다.