Test sharding

Lo sharding divide una suite in N parti più o meno uguali ed esegue ciascuna parte come job separato, di solito su macchine di CI distinte. È un livello sopra i worker paralleli: i worker eseguono test in modo concorrente all’interno di una macchina, mentre gli shard distribuiscono la suite su più macchine. Combinare le due cose è il modo in cui le grandi suite UI restano entro tempi di pipeline ragionevoli.

Esempio (Playwright e GitHub Actions)

Playwright supporta lo sharding con un solo flag:

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

In CI, una matrix avvia un job per shard. Ogni shard scrive un blob report e un job finale li unisce in un unico report 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

Il job di merge scarica ogni artifact blob-report-* in un’unica cartella ed esegue npx playwright merge-reports --reporter html ./all-blob-reports.

Come vengono distribuiti i test

Playwright divide per file di test, a meno che non sia impostato fullyParallel: true: in quel caso bilancia i singoli test tra gli shard. Con la divisione per file, un unico file spec enorme può rendere uno shard molto più lento degli altri, quindi mantieni i file di dimensioni ragionevoli.

Errori comuni

• Fare sharding di una suite non isolata. I test che condividono dati o dipendono dall’ordine passano su una macchina e falliscono quando vengono divisi. Prima sistema l’isolamento.
• Perdere il risultato complessivo. Senza un passo di merge, i fallimenti sono sparsi in N log di job e N report.
• Troppi shard. Ogni shard paga il costo fisso di checkout, installazione e download dei browser. Oltre un certo punto, più shard aggiungono costi senza far risparmiare tempo.
• fail-fast lasciato attivo. Uno shard che fallisce annulla gli altri e perdi il resto dei risultati.