Lección 4 de 7 · 2 min
Paralelismo, proyectos y sharding
Al terminar sabrás
10 min- Paralelizar dentro y entre archivos con workers y fullyParallel
- Correr una suite en varias configuraciones con projects (móvil, firefox…)
- Repartir una suite grande entre máquinas con sharding en CI
Construyes: Una suite existente corriendo en paralelo con 4 workers y sus acoplamientos arreglados.
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.serialsalvo 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).
Comprueba lo aprendido en el quiz y paraleliza tu suite en el reto.
Compruébalo
0/3Responde sin mirar atrás. Verás la explicación al instante.
1. Tienes 8 workers pero un archivo de 20 tests corre secuencial. ¿Qué falta?
2. ¿Cuál es el requisito para paralelizar sin dolor?
3. La suite tarda 40 min y ni el paralelismo local alcanza. ¿Qué usas?
Reto: activa el paralelismo y encuentra acoplamientos
Toma una suite existente y actívale fullyParallel con 4 workers.
Anota qué tests fallan y arréglalos con fixtures de datos propios.