Cypress cambia la forma de tratar los reintentos en CI
Los reintentos de Cypress ya no son un simple “paso” automático: ahora la prueba debe decidir si el fallo inicial cuenta para la entrega final.
Cypress ha introducido una política explícita de reintentos que separa el resultado final de la historia de intentos.
Al ejecutar una suite, el primer fallo sigue siendo visible en los artefactos: capturas de pantalla con sufijo de intento y logs de la ejecución. La configuración por defecto, retries.runMode: 2, openMode: 0, simplemente reintenta hasta que pase, marcando el test como pass si cualquier intento lo logra.
Para entornos de release crítico, Cypress permite una estrategia experimental: experimentalStrategy: "detect-flake-but-always-fail" con stopIfAnyPassed: true. En esta política, cualquier fallo en cualquier intento anula la prueba, aunque un reintento posterior lo haga pasar.
El código de configuración:
import { defineConfig } from "cypress";
export default defineConfig({
retries: {
experimentalStrategy: "detect-flake-but-always-fail",
experimentalOptions: {
maxRetries: 2,
stopIfAnyPassed: true,
},
openMode: true,
runMode: true,
},
});
Esta opción es global y se recomienda fijar la versión de Cypress para evitar cambios futuros. Además, los artefactos de los intentos fallidos se conservan tanto en Cypress Cloud como en el CI local, permitiendo triage.
Para analizar la causa de la flakiness, el artículo sugiere clasificar los fallos antes de aumentar los reintentos:
- Riesgo de aplicación – estado intermedio visible, modelo de estado incorrecto o tiempo de espera inadecuado.
- Riesgo de prueba – uso de
sleep, lecturas prematuras. - Fugas de estado – dependencias compartidas, cachés no limpiados.
- Inestabilidad de dependencias – servicios externos no stubeados.
Una vez identificada la clase, se puede establecer un umbral de flakiness. Por ejemplo, un pipeline puede aceptar hasta maxFlakyTests mientras no haya pruebas con fallos críticos.
El objetivo es diferenciar un pass estable de un pass frágil: el primero indica fiabilidad, el segundo solo que el test pudo pasar en algún intento. Esta distinción evita que un test intermitente desestabilice el flujo de liberación.
Para más detalles sobre reintentos y la configuración experimental, consulta la documentación oficial:
