Paralelismo, proyectos y sharding

Paralelismo nativo

Playwright corre archivos en paralelo por defecto, un worker por core. Cada worker es un proceso con su propio navegador — aislamiento real:

// playwright.config.ts
workers: process.env.CI ? 4 : undefined,  // local: automático
fullyParallel: true,  // paraleliza también DENTRO de cada archivo

fullyParallel es el multiplicador que muchos olvidan: sin él, un archivo de 20 tests es secuencial aunque tengas 8 workers.

El requisito: aislamiento total

Para paralelizar sin dolor, cada test debe poder correr solo y en cualquier orden:

• Datos propios por test — sembrados por API en fixtures, con teardown.
• Nada de test.describe.serial salvo justificación escrita — es una deuda declarada.
• Cuidado con recursos únicos (el mismo usuario admin mutando estado): usa una cuenta por worker con workerIndex.

const user = `admin-w${test.info().workerIndex}@test.cl`;

Proyectos: una suite, N configuraciones

projects: [
  { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  { name: 'mobile', use: { ...devices['iPhone 14'] } },
  { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
]

Los mismos tests corren en cada proyecto — móvil no es una suite duplicada, es una dimensión de configuración. Y se filtra fino cuando algo aplica a uno solo:

test.skip(({ isMobile }) => isMobile, 'El hover no existe en táctil');

Sharding: la suite grande en CI

Cuando ni el paralelismo local alcanza, reparte la suite entre máquinas:

strategy:
  matrix:
    shard: [1/4, 2/4, 3/4, 4/4]
steps:
  - run: npx playwright test --shard=${{ matrix.shard }}

Cuatro máquinas, un cuarto de suite cada una, y merge-reports junta el reporte final. Una suite de 40 minutos baja a ~10 sin tocar un test.

El presupuesto de tiempo

Regla operativa que recomendamos: la suite completa bajo 10 minutos. Sobre eso, la gente deja de esperarla antes de mergear, y una suite que no se espera es decorativa. Palancas en orden de costo/beneficio: fullyParallel → más workers → sharding → auditar los 10 tests más lentos (--reporter=list los muestra).

Ejercicio

Toma una suite existente y actívale fullyParallel con 4 workers. Anota qué tests fallan — cada fallo nuevo es un acoplamiento de datos que acabas de descubrir gratis. Arréglalos con fixtures de datos propios.