Sharding de testes

O sharding divide uma suíte em N partes mais ou menos iguais e roda cada parte como um job separado, normalmente em máquinas de CI diferentes. É um nível acima dos workers paralelos: os workers rodam testes de forma concorrente dentro de uma máquina, enquanto os shards espalham a suíte por várias máquinas. Combinar os dois é o que mantém grandes suítes de UI dentro de um tempo de pipeline razoável.

Exemplo (Playwright e GitHub Actions)

O Playwright suporta sharding com uma única flag:

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

No CI, uma matrix inicia um job por shard. Cada shard grava um blob report, e um job final os mescla em um único relatório 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

O job de merge baixa todos os artefatos blob-report-* para uma única pasta e roda npx playwright merge-reports --reporter html ./all-blob-reports.

Como os testes são distribuídos

O Playwright divide por arquivo de teste, a menos que fullyParallel: true esteja definido; nesse caso, ele equilibra testes individuais entre os shards. Com a divisão por arquivo, um único spec gigante pode deixar um shard muito mais lento que os outros, então mantenha os arquivos com um tamanho razoável.

Erros comuns

• Fazer sharding de uma suíte que não é isolada. Testes que compartilham dados ou dependem da ordem passam em uma máquina e falham quando divididos. Corrija o isolamento primeiro.
• Perder o resultado geral. Sem uma etapa de merge, as falhas ficam espalhadas por N logs de job e N relatórios.
• Shards demais. Cada shard paga o custo fixo de checkout, instalação e download dos navegadores. A partir de certo ponto, mais shards aumentam o custo sem economizar tempo.
• fail-fast ligado. Um shard que falha cancela os outros, e você perde o restante dos resultados.