Tests flaky: causas, cómo detectarlos y una estrategia de cuarentena

Respuesta corta: un test flaky es el que a veces pasa y a veces falla sin que haya cambiado el código. Casi siempre se debe a tiempos de espera, datos compartidos entre pruebas, diferencias de entorno o animaciones. La estrategia que funciona es detectarlos con reintentos y trazas, corregir la causa raíz y, mientras tanto, ponerlos en cuarentena con un plazo, no ignorarlos.

Por qué importan más de lo que parece

El daño de un test flaky no es el tiempo que cuesta reejecutarlo: es que el equipo deja de creer en la suite. Cuando "el rojo suele ser un falso positivo", la gente reintenta hasta que pasa, y un fallo real termina pasando inadvertido.

Las causas más comunes

1. Condiciones de carrera: el test avanza más rápido que la aplicación (por ejemplo, hace clic antes de que el elemento esté listo).
2. Estado compartido: un test deja datos que rompen al siguiente, o dependen del orden de ejecución.
3. Diferencias de entorno: versiones de navegador distintas, recursos limitados en CI, zonas horarias o datos de la base que cambian.
4. Animaciones y transiciones que tapan un elemento justo cuando el test interactúa.
5. Dependencias externas (APIs de terceros, correos, pagos) que responden lento o fallan.
6. Esperas fijas (waitForTimeout) en lugar de esperar a una condición real.

Cómo detectarlos

Playwright marca como flaky un test que falla en el primer intento y pasa al reintentar. Con una configuración mínima ya tienes detección sin infraestructura adicional:

// playwright.config.ts
import { defineConfig } from "@playwright/test";

export default defineConfig({
  fullyParallel: true,
  retries: process.env.CI ? 2 : 0,
  use: {
    trace: "on-first-retry", // guarda DOM, red y consola cuando algo falla
  },
});

Con trace: "on-first-retry" obtienes la evidencia justo en el momento en que el test se comporta raro, que es lo más difícil de reproducir después. Para confirmar si un test es inestable, ejecútalo muchas veces seguidas:

npx playwright test tests/checkout.spec.ts --repeat-each=20

Cómo corregirlos de verdad

• Reemplaza esperas fijas por esperas basadas en condiciones: usa las aserciones de Playwright (expect(locator).toBeVisible()), que esperan y reintentan solas.
• Aísla los datos: cada test crea los suyos y no depende de otro.
• Controla las dependencias externas: simula (mock) respuestas de terceros en las pruebas que no necesitan integrarse de verdad.
• Fija el entorno: versión de navegador y de dependencias, y la misma imagen en CI y en local.

Estrategia de cuarentena (para no frenar al equipo)

Si un test inestable bloquea los Pull Requests, no lo borres ni lo ignores en silencio: ponlo en cuarentena con reglas claras.

test("checkout con cupón", { tag: "@quarantine" }, async ({ page }) => {
  // ...
});

# Pull Requests: excluye la cuarentena
npx playwright test --grep-invert @quarantine

# Ejecución nocturna: solo la cuarentena, para seguir midiéndola
npx playwright test --grep @quarantine

Reglas que lo hacen funcionar:

1. Todo test en cuarentena tiene dueño y fecha límite (por ejemplo, cinco días hábiles).
2. Al vencer el plazo, se corrige o se elimina. Una cuarentena sin fecha es solo un cementerio.
3. Se publica la lista en el tablero del equipo, para que sea visible.
4. Se mide la tasa de flakiness (porcentaje de ejecuciones inestables) y se vigila que baje.

Una señal de madurez

Un equipo con una suite sana no es el que "nunca tiene tests inestables", sino el que los detecta rápido, los trata como defectos y no permite que se acumulen.

Si quieres profundizar en cómo construir una suite confiable desde el inicio, revisa qué automatizar primero y Playwright con IA: qué sirve y qué no.

¿Tu suite de pruebas pierde credibilidad por los falsos fallos? Conversemos y la revisamos juntos.