On the Flakiness of LLM-Generated Tests for Industrial and Open-Source Database Management Systems

Resumen Técnico: Sobre la inestabilidad de las pruebas generadas por LLM para Sistemas de Gestión de Bases de Datos Industriales y de Código Abierto

Planteamiento del Problema
Las pruebas inestables (flaky tests), que producen resultados inconsistentes al ejecutarse múltiples veces sobre el mismo estado del código, representan un desafío significativo en las pruebas de software industrial, reduciendo la eficiencia y erosionando la confianza del desarrollador. Aunque trabajos recientes han identificado la inestabilidad como un problema potencial en las pruebas generadas por Modelos de Lenguaje de Gran Escala (LLM), la prevalencia, las causas raíz y los mecanismos de transferencia de inestabilidad en este contexto siguen sin estar claros. Este estudio aborda la brecha en la investigación dedicada a la inestabilidad de las pruebas generadas por LLM, específicamente en el contexto de los Sistemas de Gestión de Bases de Datos (DBMS), donde la fiabilidad de las pruebas es crítica para las operaciones comerciales.

Metodología
Los autores realizaron un estudio empírico que involucró cuatro DBMS: el sistema industrial de código cerrado SAP HANA, y tres sistemas de código abierto (MySQL, DuckDB y SQLite). El estudio se centró en dos tipos de pruebas: pruebas unitarias nativas en C++ y pruebas de sistema SQL.

• Enfoque de Generación de Pruebas: Los investigadores adoptaron una estrategia de amplificación de pruebas inspirada en Alshahwan et al. [5], solicitando a los LLM que generaran versiones extendidas de archivos de prueba existentes para cubrir casos de esquina (corner cases) adicionales.
• Modelos: Se evaluaron dos LLM: GPT-4o (seleccionado por su alto rendimiento y capacidad para manejar el código interno de SAP HANA) y Mistral-Large-Instruct-2407 (seleccionado como alternativa de código abierto para la reproducibilidad). Ambos modelos se ejecutaron con una temperatura de cero para maximizar las tasas de éxito de compilación.
• Entorno de Ejecución: Para aislar la inestabilidad causada por el código generado en lugar del ruido ambiental, las pruebas se ejecutaron 30 veces cada una dentro de contenedores Docker aislados. Las pruebas de C++ se ejecutaron individualmente, mientras que las pruebas SQL se ejecutaron en orden de archivo para respetar el diseño de los respectivos marcos de trabajo (frameworks).
• Detección de Inestabilidad: Una prueba se clasificó como inestable si producía tanto resultados de éxito como de fallo a través de las 30 ejecuciones.
• Experimento de Transferencia de Inestabilidad: Para evaluar la susceptibilidad a la "transferencia de inestabilidad", los autores inyectaron una aserción no determinista (que falla con un 50% de probabilidad) en archivos de prueba existentes antes de solicitar a los LLM que generaran nuevas pruebas.

Contribuciones Clave

1. Análisis de Prevalencia: Una evaluación cuantitativa de la proporción de pruebas inestables en el código generado por LLM en comparación con las pruebas existentes escritas por humanos en cuatro DBMS.
2. Identificación de la Causa Raíz: Una inspección manual y categorización de las causas raíz de la inestabilidad en las pruebas generadas por LLM, distinguiendo entre problemas derivados del proceso de generación y aquellos transferidos desde el contexto.
3. Benchmark de Transferencia de Inestabilidad: Una evaluación experimental del grado en que los LLM transfieren patrones de inestabilidad de los ejemplos proporcionados en el contexto a la nueva generación de código, comparando el rendimiento entre contextos de código cerrado (SAP HANA) y de código abierto (MySQL).

Resultos

• Tasas de Compilación y Éxito: Los LLM tuvieron dificultades significativas para generar código C++ compilable para el proyecto de código cerrado SAP HANA (Tasa de Éxito de Compilación de ~40-46%), debido a la falta de datos de entrenamiento del modelo sobre ese código base específico. En contraste, la generación de pruebas SQL mostró altas tasas de aprobación (81-95%).
• Prevalencia de Inestabilidad: La proporción de pruebas inestables en el código generado por LLM fue generalmente ligeramente superior a la de las pruebas existentes.
  • Para las pruebas de C++, GPT-4o generó un 0.29% de pruebas inestables para SAP HANA y un 0.18% para MySQL, mientras que Mistral generó tasas ligeramente superiores (0.39% y 0.71%, respectivamente).
  • Para las pruebas SQL, donde no se encontraron pruebas inestables existentes en las suites originales, los LLM generaron 96 pruebas inestables en total (43 por GPT-4o, 53 por Mistral).
• Causas Raíz: La causa raíz más prevalente de la inestabilidad en las pruebas generadas por LLM fue "Colección Desordenada" (Unordered Collection) (63% de 115 pruebas inestables). Esto ocurrió cuando los LLM generaron consultas SQL asumiendo un orden específico de resultados sin utilizar ORDER BY, lo que provocó fallos intermitentes.
  • La inestabilidad por NIO (Resultado No Idempotente) fue la segunda causa más común (10%), resultando a menudo de que el LLM imitara pruebas existentes que contaminaban el entorno de ejecución.
  • Los problemas de concurrencia se observaron principalmente en las pruebas generadas por Mistral.
• Transferencia de Inestabilidad: Ambos LLM demostraron susceptibilidad a transferir la inestabilidad inyectada desde el contexto del prompt a las pruebas generadas.
  • En el contexto de SAP HANA (código cerrado, sin datos de entrenamiento), la tasa de transferencia fue mayor (~69-78% de las pruebas generadas contenían la aserción inestable inyectada).
  • En el contexto de MySQL (código abierto, probablemente presente en los datos de entrenamiento), la tasa de transferencia fue menor (~41-58%).
  • Esto sugiere que los LLM dependen más fuertemente del contexto proporcionado cuando carecen de conocimiento previo del sistema, pudiendo adoptar correlaciones espurias (como aserciones inestables) como patrones de codificación válidos.

Significancia y Reivindicaciones
El artículo afirma proporcionar los primeros conocimientos dedicados sobre la inestabilidad de las pruebas generadas por LLM para sistemas de bases de datos. Los autores concluyen que, si bien los LLM pueden generar código de prueba con apariencia natural, introducen riesgos específicos de inestabilidad, particularmente en relación con estructuras de datos desordenadas y la transferencia de defectos existentes.

El estudio destaca que la transferencia de inestabilidad es un problema crítico, especialmente en entornos de código cerrado donde los modelos carecen de datos de entrenamiento y dependen fuertemente del aprendizaje en contexto (in-context learning). En consecuencia, los autores aconsejan a los profesionales priorizar la corrección de las pruebas inestables existentes antes de aplicar enfoques de generación basados en LLM para evitar la propagación de la inestabilidad. También enfatizan la necesidad de proporcionar a los LLM un contexto adaptado para mitigar causas raíz como las suposiciones de "colección desordenada", señalando que las ventanas de contexto actuales pueden ser insuficientes para sistemas grandes como SAP HANA. Los hallazgos sirven como una base de referencia cautelosa para desarrolladores e investigadores que buscan integrar LLM en procesos de pruebas automatizadas.