Test sharding

El sharding divide una suite en N partes aproximadamente iguales y ejecuta cada parte como un job independiente, normalmente en máquinas de CI distintas. Está un nivel por encima de los workers en paralelo: los workers ejecutan tests de forma concurrente dentro de una máquina, mientras que los shards reparten la suite entre varias máquinas. Combinar ambos es la forma en que las grandes suites de UI se mantienen dentro de un tiempo de pipeline razonable.

Ejemplo (Playwright y GitHub Actions)

Playwright admite sharding con un solo flag:

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

En CI, una matriz lanza un job por shard. Cada shard escribe un blob report y un job final los fusiona en un único informe 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

El job de fusión descarga cada artifact blob-report-* en una carpeta y ejecuta npx playwright merge-reports --reporter html ./all-blob-reports.

Cómo se reparten los tests

Playwright divide por archivo de test salvo que se configure fullyParallel: true, en cuyo caso equilibra los tests individuales entre los shards. Con la división por archivo, un único spec enorme puede hacer que un shard sea mucho más lento que los demás, así que mantén los archivos de un tamaño razonable.

Errores comunes

• Hacer sharding de una suite que no está aislada. Los tests que comparten datos o dependen del orden pasan en una máquina y fallan al dividirse. Arregla primero el aislamiento.
• Perder el resultado global. Sin un paso de fusión, los fallos quedan dispersos entre N logs de jobs y N informes.
• Demasiados shards. Cada shard paga el coste fijo del checkout, la instalación y la descarga de navegadores. A partir de cierto punto, más shards añaden coste sin ahorrar tiempo.
• Dejar fail-fast activado. Un shard que falla cancela los demás y pierdes el resto de los resultados.