Automated Generation of Issue-Reproducing Tests by Combining LLMs and Search-Based Testing

El artículo presenta BLAST, una herramienta que combina modelos de lenguaje grandes y pruebas de software basadas en búsqueda para generar automáticamente pruebas que reproducen errores a partir de pares de problemas y parches, logrando un rendimiento superior al estado del arte y validando su utilidad práctica mediante un bot desplegado en repositorios de GitHub.

Lo esencial

¡Claro que sí! Imagina que el desarrollo de software es como construir una casa gigante y compleja. A veces, los arquitectos (los desarrolladores) cometen un error: una puerta que no cierra bien, una ventana que se rompe o un grifo que gotea. Esto es un "bug" o fallo.

Cuando alguien reporta el problema, los desarrolladores hacen una "parche" (una reparación) para arreglarlo. Pero, ¿cómo sabemos que el parche realmente funciona y que no volverá a ocurrir el mismo problema mañana? Aquí es donde entra la estrella de esta historia: BLAST.

¿Qué es BLAST?

BLAST es como un detective de software superpoderoso que tiene dos ayudantes muy diferentes pero que trabajan en equipo:

1. El LLM (El "Genio" Creativo): Imagina a un escritor muy inteligente que ha leído millones de libros de código. Puede entender el problema descrito en lenguaje humano ("la puerta no cierra") e intentar escribir una prueba para ver si la puerta funciona.

   • El problema: A veces, este genio es demasiado imaginativo. Puede inventar cosas que no existen (alucinaciones), como decir "usa la cerradura mágica" cuando en realidad esa cerradura no existe en la casa.

2. El SBST (El "Mecánico" Metódico): Imagina a un mecánico que no lee libros, sino que prueba físicamente cada tornillo, cada puerta y cada ventana una y otra vez, de forma sistemática, hasta encontrar dónde está el fallo. Es lento pero muy preciso y no inventa cosas.

   • El problema: A veces, el mecánico prueba cosas al azar y no sabe exactamente qué puerta es la que el cliente dijo que estaba rota.

¿Cómo funciona BLAST? (La Magia del Equipo)

BLAST combina a estos dos personajes para que se ayuden mutuamente:

• Paso 1: El Mecánico (SBST) empieza a trabajar.
  El mecánico toma el parche (la reparación) y empieza a probar el código. Pero, para no perder tiempo probando cosas al azar, le pide al "Genio" (LLM) una pista. El Genio lee la descripción del problema y le da al mecánico una "semilla" (un punto de partida inteligente).

  • Analogía: Es como si el Genio le dijera al mecánico: "Oye, el problema es en la puerta de atrás, empieza probando esa".

• Paso 2: El Mecánico genera pruebas reales.
  Con esa pista, el mecánico genera pruebas que funcionan perfectamente en la versión reparada. Estas pruebas son como "certificados de seguridad" que aseguran que la puerta ahora cierra bien.

• Paso 3: El Genio (LLM) usa la información.
  Ahora, el Genio no solo lee la descripción del problema, sino que también ve las pruebas reales que hizo el mecánico. Esto le ayuda a no alucinar. El Genio dice: "Ah, veo que el mecánico probó la puerta de atrás y funcionó. Ahora voy a escribir una prueba que demuestre que antes no funcionaba".

• El Resultado: BLAST crea una prueba que falla en el código roto (demostrando que el problema existía) y pasa en el código reparado (demostrando que el parche funcionó).

¿Funcionó en la vida real?

Los autores no solo lo probaron en un laboratorio (con datos antiguos), sino que crearon un bot de GitHub (un pequeño robot automático) que se instaló en tres proyectos de código abierto reales (como si fuera un inspector de obra que llega cada vez que alguien envía una reparación).

• En el laboratorio: BLAST encontró y creó pruebas exitosas en el 35.4% de los casos, superando a las técnicas anteriores (que solo llegaban al 23.5%).
• En la vida real: El robot se activó 32 veces. En 11 ocasiones, logró crear una prueba útil. Los desarrolladores humanos revisaron estas pruebas y dijeron: "¡Sí, esto funciona!" en la mitad de los casos.

¿Qué aprendimos? (Las lecciones)

1. La combinación es clave: Usar solo al "Genio" (IA) es arriesgado porque inventa cosas. Usar solo al "Mecánico" es lento y a veces no entiende el contexto. Juntos son mucho mejores.
2. No todo necesita una prueba: A veces, los desarrolladores arreglan algo tan pequeño (como cambiar un nombre) que no vale la pena escribir una prueba automática. El bot a veces sugería pruebas para cosas que no las necesitaban.
3. Los humanos son importantes: Aunque la IA puede hacer mucho, los desarrolladores reales deben validar si la prueba es realmente útil. A veces la IA crea una prueba que técnicamente funciona, pero no prueba la parte importante del problema.

En resumen

BLAST es como tener un arquitecto y un albañil trabajando juntos. El arquitecto entiende la visión del problema, y el albañil asegura que los ladrillos estén bien puestos. Juntos, pueden crear un "testigo" (una prueba) que garantiza que el error no volverá a ocurrir, haciendo que el software sea más seguro y confiable para todos nosotros.

¡Es un gran paso para que la inteligencia artificial ayude a los humanos a escribir código más limpio y sin errores!

Resumen técnico

Aquí tienes un resumen técnico detallado del artículo "Automated Generation of Issue-Reproducing Tests by Combining LLMs and Search-Based Testing" (Generación Automatizada de Pruebas de Reproducción de Problemas Combinando LLMs y Pruebas Basadas en Búsqueda), presentado por Kitsios, Castelluccio y Bacchelli.

---

1. El Problema

En el desarrollo de software, cuando un desarrollador corrige un error (issue) mediante un parche, es crucial incluir una prueba de reproducción del problema (issue-reproducing test). Esta prueba debe fallar en el código original (no parcheado) para validar la existencia del error y pasar en el código corregido para confirmar la solución.

Sin embargo, los desarrolladores a menudo omiten escribir estas pruebas debido a que es una tarea demandante y consume tiempo. La investigación previa ha intentado automatizar este proceso utilizando principalmente Modelos de Lenguaje Grande (LLMs). No obstante, los enfoques puramente basados en LLMs presentan limitaciones:

• Alucinaciones: Los LLMs pueden generar código con sintaxis incorrecta, importar módulos inexistentes o usar métodos que no existen.
• Falta de contexto: A menudo carecen de información crítica sobre la estructura del código existente, el contexto focal o cómo configurar las pruebas (mocks).
• Memorización: Las evaluaciones basadas en datos históricos pueden inflar los resultados si el modelo ha memorizado los casos de prueba en lugar de aprender a generarlos.

2. Metodología: BLAST

Los autores proponen BLAST (Bug-reproducing tests using LLMs and Search-based software Testing), una herramienta híbrida que combina la capacidad de generación de código de los LLMs con la robustez y corrección sintáctica de las Pruebas Basadas en Búsqueda de Software (SBST).

La arquitectura de BLAST consta de dos componentes principales que trabajan en coordinación (ver Figura 3 del artículo):

A. Componente SBST (Basado en Pynguin)

Este componente adapta las herramientas SBST (específicamente Pynguin para Python) para generar pruebas que revelen diferencias entre el código con y sin parche.

• Semilla (Seeding): Dado que Pynguin no entiende lenguaje natural, BLAST utiliza un LLM para generar una "semilla" de prueba basada en la descripción del problema y el parche.
• Deserialización: Un middleware analiza estáticamente la semilla generada por el LLM para filtrar declaraciones que violan el formato canónico de Pynguin, aumentando la tasa de aceptación de las semillas.
• Ejecución y Filtrado: Pynguin genera pruebas para el módulo parcheado. Luego, BLAST ejecuta estas pruebas en el código no parcheado. Si una prueba falla en el código original pero pasa en el parcheado, se clasifica como una prueba de reproducción del problema (Fail-to-Pass o F→P).

B. Componente LLM

Este componente genera una segunda candidata a prueba utilizando un prompt enriquecido con múltiples fuentes de contexto:

1. Descripción del problema y el parche.
2. Contexto Focal: Información sobre las firmas de clases, métodos y constructores afectados.
3. Pruebas Existentes: Recuperación de archivos de prueba acoplados temporalmente al código modificado (usando heurísticas de nombres y git) para aprender sobre la configuración de pruebas y mocks.
4. Pruebas Generadas por SBST: Las pruebas exitosas generadas por el componente SBST se inyectan en el prompt del LLM. Esto sirve como contexto sintácticamente correcto para reducir alucinaciones y guiar al modelo.

El LLM genera una función de prueba cruda que luego se inyecta en el archivo de prueba adecuado.

3. Contribuciones Clave

1. Técnica Híbrida (BLAST): Una nueva metodología que orquesta LLMs y SBST para superar las limitaciones de cada enfoque por separado.
2. Nuevo Conjunto de Datos (PyngBench): Creación y liberación de un benchmark específico para evaluar herramientas SBST en la tarea de generación de pruebas de reproducción de problemas, filtrando casos incompatibles.
3. Evaluación en Vivo (In Vivo): Desarrollo y despliegue de un bot de GitHub que ejecuta BLAST en repositorios de código abierto reales (Mozilla) durante tres meses, evaluando la utilidad real y la percepción de los desarrolladores, más allá de los datos históricos.
4. Análisis de Métricas: Evidencia de que la métrica estándar "Fail-to-Pass" (F→P) no siempre garantiza que una prueba reproduzca el problema real (puede fallar por razones secundarias), proponiendo la necesidad de validación manual y de desarrolladores.

4. Resultados

Evaluación en Benchmark (Datos Históricos)

Se evaluó BLAST en un conjunto de datos filtrado de 426 pares de problema-parche (TDD-Bench-Verified) de 12 repositorios de Python.

• Rendimiento: BLAST generó pruebas de reproducción exitosas en el 35.4% de los casos (151/426).
• Comparación: Superó al estado del arte (AutoTDD, basado puramente en LLMs) que logró un 23.5% (100/426).
• Eficiencia: BLAST logró esto utilizando solo 2 consultas a LLM + 1 generación SBST, mientras que el SOTA requería 3 consultas a LLM.
• Contribución de SBST: El componente SBST generó pruebas únicas en 10 casos que el LLM falló, y sus pruebas sirvieron como contexto para mejorar el rendimiento del LLM en otros 5 casos (contribución total del 7.3% en los casos exitosos).

Evaluación en Vivo (Despliegue Real)

El bot se desplegó en 3 repositorios de Mozilla, procesando 32 Pull Requests (PRs) vinculados a problemas.

• Generación: BLAST generó pruebas F→P en 11 de 32 casos (34.4%).
• Validación de Desarrolladores: De las 11 pruebas propuestas a los desarrolladores, 6 fueron consideradas válidas (55%).
• Integración: 2 pruebas fueron aceptadas e integradas directamente en la suite de pruebas del proyecto (una sin cambios, otra con ajustes menores).
• Lecciones: Se identificaron desafíos como pruebas con "mocking" excesivo, problemas que no requerían pruebas (ej. renombramientos) y la necesidad de activar el bot bajo demanda o en etapas específicas del PR para no saturar a los desarrolladores.

5. Significado e Implicaciones

• Más allá de los LLMs: El trabajo demuestra que combinar LLMs con técnicas tradicionales de ingeniería de software (SBST) mejora significativamente la calidad y la tasa de éxito en la generación de pruebas, mitigando alucinaciones.
• Calidad de los Datos: Destaca la importancia de limpiar los benchmarks históricos, ya que muchos casos "triviales" (donde la prueba ya existía en el input) inflaban artificialmente los resultados de modelos anteriores.
• Perspectiva del Desarrollador: La evaluación en vivo revela que la métrica técnica (F→P) no es suficiente; la utilidad real depende de si la prueba captura la lógica crítica del negocio y si es aceptable para el mantenedor del código.
• Futuro: Sugiere que las herramientas SBST deben evolucionar para soportar objetivos de prueba más granulares (métodos específicos en lugar de módulos completos) y para manejar código más complejo (decoradores, introspección dinámica) para aumentar su contribución en entornos híbridos.

En resumen, BLAST representa un avance significativo hacia la automatización práctica de la creación de pruebas de regresión, ofreciendo una solución más robusta y confiable que los enfoques puramente generativos basados en IA.