¿Pueden los LLM encontrar flaky tests a partir del código? El estudio dice que no

Las pruebas flaky son pruebas que a veces fallan, a veces pasan, sin razón aparente. Rompen CI/CD, fuerzan rehacer trabajo y socavan la confianza en las pruebas automatizadas. Los investigadores decidieron confiar este problema a los LLMs: ¿puede una red neuronal entender el código y encontrar pruebas sospechosas? Los resultados fueron decepcionantes.

Por qué las pruebas flaky son un enemigo peor

Una prueba no fiable no es solo un bug. Cuando una prueba falla en momentos aleatorios, los ingenieros dejan de confiar en ella. Rehacen trabajo, reinician el pipeline, pasan horas depurando. Un bug clásico puede reproducirse; una prueba flaky solo se reproduce el lunes a las 3:43 de la mañana. Esto mata la velocidad de desarrollo.

Las fuentes de pruebas flaky son diversas y a menudo ocultas:

• Condiciones de carrera y problemas de temporización
• Dependencias del estado de la base de datos o del sistema de archivos
• Pruebas mal aisladas que se afectan mutuamente
• Código asincrónico sin esperas apropiadas
• Tiempos límite rígidos que no toleran sobrecarga del servidor

Cómo los investigadores probaron los LLMs

Un equipo tomó varios LLMs e hizo una pregunta simple: ¿es este código de prueba flaky? Los modelos analizaron el código fuente, intentaron identificar patrones (lógica de reintentos, sleep, aislamiento débil) y proporcionaron una probabilidad de problema. En un conjunto de datos controlado, los resultados se veían excelentes: los modelos lograron una precisión del 85%+. Precision y recall fueron buenos, los gráficos se veían como proyectos ML típicamente exitosos. Parecía que el problema estaba resuelto.

Pero aquí está la paradoja: cuando los investigadores aplicaron los mismos modelos a pruebas reales de otros proyectos, el efecto casi desapareció. La precisión bajó, los falsos positivos aumentaron. El modelo claramente no entendió la naturaleza del comportamiento flaky.

Por qué las métricas no son iguales a la comprensión

Esta es una trampa clásica del machine learning, olvidada entre leer artículos sobre nuevos modelos y trabajo real. Un modelo puede aprender correlaciones en un conjunto de datos, pero eso no significa que entendió la causa. Por ejemplo, si todas las pruebas flaky en el conjunto de datos de entrenamiento contenían `Thread.sleep()`, el modelo marcará cualquier prueba con esa función como sospechosa — incluso si el sleep se usa correctamente para sincronización.

Para pruebas flaky, el problema es agudo: cada proyecto tiene sus propios patrones de violación. Lo que se rompe en una arquitectura de microservicios puede ser completamente normal en una aplicación monotarea. Los modelos se entrenaron en un corte de datos y no ven el contexto ambiental, las versiones de frameworks o las especificidades de la infraestructura.

Las buenas métricas en un conjunto de pruebas son necesarias pero no suficientes.

Necesitas validación real en ejemplos en producción.

Qué significa esto

Los LLMs son herramientas poderosas, pero no son magia. Para problemas especializados como encontrar pruebas flaky, necesitas más contexto (historial de fallos, metadatos ambientales, información de carga) o un enfoque híbrido (LLM + análisis estático + monitoreo de fallos en producción). La moraleja es simple: no confíes solo en métricas. Las tareas específicas requieren un enfoque específico.