¿Pueden los LLM detectar tests inestables solo con el código? Un estudio dice que no

Los flaky tests son tests que unas veces fallan y otras pasan, sin una razón visible. Rompen el CI/CD, obligan a rehacer trabajo y minan la confianza en las pruebas automáticas. Los investigadores decidieron encargar el problema a los LLM: ¿y si una red neuronal es capaz de entender el código y señalar los tests sospechosos? Los resultados decepcionaron.

Por qué los flaky tests son un enemigo tan molesto

Un test poco fiable no es solo un bug. Cuando un test falla en momentos aleatorios, los ingenieros dejan de confiar en él. Rehacen el trabajo, relanzan el pipeline y pierden horas depurando. Un bug clásico se puede reproducir; un flaky test solo se reproduce el lunes a las 3:43 de la madrugada. Eso mata la velocidad de desarrollo.

Las fuentes de los flaky tests son variadas y a menudo están ocultas:

• Race conditions y problemas de timing
• Dependencias del estado de la base de datos o del sistema de archivos
• Tests mal aislados que se afectan entre sí
• Código asíncrono sin esperas (waits) adecuadas
• Timeouts rígidos que no soportan la sobrecarga del servidor

Cómo probaron los investigadores los LLM

El equipo tomó varios LLM y les planteó una pregunta sencilla: este es el código de un test, ¿es flaky? Los modelos analizaron el código fuente, intentaron reconocer patrones (lógica de retry, sleep, aislamiento débil) y devolvieron una probabilidad de que hubiera un problema.

En un dataset controlado los resultados parecían excelentes: los modelos alcanzaban más de un 85 % de precisión. Precision y recall eran buenos, y las gráficas se parecían a las de cualquier proyecto de ML exitoso. El problema parecía resuelto.

Pero aquí llega la paradoja: cuando los investigadores aplicaron los mismos modelos a tests reales de otros proyectos, el efecto casi se esfumó. La precisión cayó y los falsos positivos aumentaron. Era evidente que el modelo no había entendido la naturaleza del comportamiento flaky.

Por qué las métricas no equivalen a comprensión

Es una trampa clásica del machine learning, que se olvida entre la lectura de artículos sobre modelos nuevos y el trabajo real. Un modelo puede aprender correlaciones del dataset, pero eso no significa que haya entendido la causa. Por ejemplo, si en el dataset de entrenamiento todos los flaky tests contenían Thread.sleep(), el modelo marcará como sospechoso cualquier test con esa función, aunque el sleep se use correctamente para sincronizar.

En los flaky tests el problema es agudo: cada proyecto tiene sus propios patrones de fallo. Lo que se rompe en una arquitectura de microservicios puede ser perfectamente normal en una aplicación de un solo hilo. Los modelos se entrenaron con una sola porción de datos y no ven el contexto del entorno, las versiones de los frameworks ni las particularidades de la infraestructura.

Las buenas métricas en el conjunto de prueba son una condición necesaria, pero no suficiente.

Hace falta una validación real con ejemplos de producción.

Qué significa esto

Los LLM son una herramienta potente, pero no son magia. Para problemas especializados como la búsqueda de flaky tests hace falta o bien más contexto (historial de fallos, metainformación del entorno, datos de carga), o bien un enfoque híbrido (LLM + análisis estático + monitorización de fallos en producción).

La moraleja es sencilla: no se fíe solo de las métricas. Las tareas específicas requieren un enfoque específico.