Lección 5 de 7 · 2 min
Visual regression y API testing
Al terminar sabrás
11 min- Usar visual regression donde aporta y evitarlo donde genera falsos rojos
- Probar APIs con el cliente request de Playwright, en el mismo runner
- Diseñar una estrategia e2e sana: qué automatizar y qué no
Construyes: La estrategia e2e de una app de reservas: qué flujos, cuáles con visual, qué por API.
Visual regression con criterio
await expect(page).toHaveScreenshot('home.png', {
maxDiffPixelRatio: 0.01,
mask: [page.getByTestId('fecha-actual')], // oculta lo que cambia siempre
});
La primera ejecución genera el baseline; las siguientes comparan pixel a pixel. Dónde aporta de verdad:
- Páginas de marketing — un rediseño de paleta (como el de este sitio) se verifica en segundos por viewport.
- Componentes de librería interna — la matriz visual completa de un botón/card.
- PDF/emails renderizados — donde el DOM no cuenta la historia completa.
Dónde NO: pantallas con datos vivos, animaciones o fechas. Ahí el visual test es una fábrica de falsos rojos que erosiona la confianza en la suite. mask y datos congelados (page.clock.setFixedTime) son obligatorios, no opcionales.
Detalle operativo importante: los screenshots dependen del sistema operativo — genera los baselines en el mismo entorno que CI (o corre visual solo en CI).
API testing con request
Playwright trae cliente HTTP con el mismo runner y reporte:
test('POST /api/bookings rechaza horario tomado', async ({ request }) => {
const primera = await request.post('/api/bookings', {
data: { servicio: 'corte', fecha: '2026-08-01T15:30' },
});
expect(primera.ok()).toBeTruthy();
const duplicada = await request.post('/api/bookings', {
data: { servicio: 'corte', fecha: '2026-08-01T15:30' },
});
expect(duplicada.status()).toBe(409);
});
El patrón ganador es híbrido: preparar y verificar por API, interactuar por UI. El e2e puro-UI es lento; el API puro no ve la pantalla; la mezcla da velocidad con cobertura real.
El cierre: la estrategia completa
Con todo el curso en la mochila, así se ve una suite e2e sana:
- Pocos tests, críticos — e2e cubre flujos de negocio, no cada permutación (eso es para unit/component).
- Locators accesibles + web-first assertions — estabilidad por construcción.
- Fixtures con datos propios — paralelismo sin miedo.
- trace on-first-retry — ningún fallo de CI sin diagnóstico.
- Verde = requisito de merge — y cuarentena inmediata para flaky.
La suite de este sitio (58 tests, ~4 minutos, verde en cada deploy) sigue exactamente estas reglas. No es magia: es no violar ninguna.
Comprueba lo aprendido en el quiz y diseña tu estrategia en el reto final.
Compruébalo
0/3Responde sin mirar atrás. Verás la explicación al instante.
1. ¿Dónde NO conviene usar visual regression?
2. ¿Cuál es el patrón híbrido ganador para e2e?
3. ¿Dónde debes generar los baselines de screenshot?
Reto final: diseña la estrategia e2e
Diseña la estrategia e2e para una app de reservas: qué 8 flujos cubrirías, cuáles llevan visual testing, qué se verifica por API.
Justifica cada exclusión — saber qué NO automatizar es la mitad senior del trabajo.