Tu suite automatizada falla al azar aproximadamente el cinco por ciento de las veces. ¿Cómo tratas los tests inestables?

Primero ponlos en cuarentena para que la suite vuelva a ser fiable, y luego arregla las causas raíz en vez de taparlas con reintentos. Las causas habituales son tiempos y sincronización (sleeps fijos, carreras), datos de test compartidos o que quedan de antes, dependencia del orden de ejecución, y entornos inestables. Se arreglan esperando a condiciones en vez de a duraciones, aislando los datos por test, y haciendo que cada test sea independiente del orden.

Lo primero que hago es parar la hemorragia, porque una suite que falla al azar se acaba ignorando, y en cuanto la gente la ignora te quedas sin red de seguridad. Así que los tests inestables van a cuarentena, a una ejecución aparte que no bloquea el pipeline, con un ticket y una persona responsable, ni borrados ni reintentados en silencio para siempre. Luego los diagnostico de verdad. El grupo más grande con diferencia es la sincronización: alguien usó un sleep fijo, o comprobó justo después de un clic mientras la petición seguía en vuelo. El arreglo es esperar a una condición, o sea a que el elemento sea interactuable o a que la llamada de red se resuelva, nunca a una duración. El segundo grupo son los datos: dos tests usando la misma cuenta, o un test que asume un estado vacío que la ejecución anterior ensució. Eso lo arreglo creando datos por test con un identificador único. El tercero es la dependencia del orden, que saco a la luz ejecutando la suite en orden aleatorio a propósito. Y llevo la tasa de inestabilidad en un panel, porque lo que no se mide vuelve a colarse. Cualquier cosa por encima de un uno por ciento la trato como un problema real.