Flaky test (prueba inestable)

Un flaky test (prueba inestable) da un resultado distinto sobre el mismo commit. Ejecútalo diez veces contra el mismo código y obtendrás algunos pases y algunos fallos. Lo que lo define es que nada ha cambiado en el producto: la variación viene de la prueba, de sus datos o de su entorno.

Por qué importa

Una suite con unos pocos flaky tests enseña al equipo a relanzar los fallos hasta que salgan en verde. Una vez instalado ese hábito, las regresiones reales también se “arreglan” relanzando. La inestabilidad además ralentiza los pipelines, porque los reintentos multiplican el tiempo de ejecución, y erosiona la confianza en la automatización más rápido que la falta de cobertura.

Causas comunes

• Tiempos. La prueba actúa antes de que la página o la API estén listas: un sleep fijo, una comprobación que lee un valor una sola vez en lugar de reintentar, o una animación que aún está en curso.
• Estado compartido. Dos pruebas escriben el mismo usuario, carrito o fila de la base de datos. Pasan por separado y fallan en paralelo o en otro orden.
• Dependencia del orden de las pruebas. Una prueba depende de datos que creó una prueba anterior.
• Entorno. Entornos de prueba lentos o compartidos, servicios de terceros, límites de peticiones (rate limits), zonas horarias y cambios de hora.
• Datos no deterministas. Entradas aleatorias sin una semilla registrada, o assertions sobre “ahora”.

Cómo tratar uno

1. Reprodúcelo. Ejecuta esa prueba en bucle (Playwright: npx playwright test my.spec.ts --repeat-each=20) y captura un trace o un vídeo de una ejecución fallida.
2. Encuentra la causa en lugar de añadir un reintento. Sustituye las pausas por esperas basadas en condiciones, como las web-first assertions en Playwright o WebDriverWait en Selenium. Da a cada prueba sus propios datos.
3. Ponlo en cuarentena si no puedes arreglarlo hoy. Sácalo del gate bloqueante y llévalo a un job no bloqueante y con seguimiento, con un responsable, para que la señal principal siga siendo fiable.
4. Sigue la tasa de flakiness a lo largo del tiempo. Los reintentos que pasan ocultan el problema a menos que el informe los muestre.

Los reintentos (retries: 2 en playwright.config.ts) son una red de seguridad razonable en CI, pero una prueba que solo pasa al reintentar sigue siendo flaky. Playwright las marca como “flaky” para que puedas verlas.