Resumen Técnico: Generación de Pruebas de Reproducción para Problemas de SWE en Java

Enunciado del Problema

El artículo aborda la brecha crítica en la ingeniería de software (SWE) automatizada para Java: la generación de pruebas de reproducción. Una prueba de reproducción se define como una prueba que falla en la base de código actual (confirmando la presencia de un problema) y pasa después de que el problema se corrige (confirmando su ausencia). Aunque los avances recientes han producido puntos de referencia y soluciones para Python, Java sigue siendo insuficientemente atendido a pesar de su dominio en el software empresarial. Las herramientas existentes centradas en Java carecen de capacidades de localización de fallos, dependen de variantes simplificadas de problemas o sufren contaminación de conjuntos de datos y sobreajuste. Además, los errores de Java empresarial a menudo difieren en distribución y complejidad de los errores de Python de código abierto, lo que requiere enfoques especializados que tengan en cuenta el sistema de tipos estático de Java y su naturaleza orientada a objetos.

Metodología

Los autores proponen e-Otter++ para Java, una adaptación de un generador de pruebas de reproducción de Python de última generación. La metodología es una tubería de múltiples etapas diseñada para manejar la complejidad a nivel de repositorio sin requerir acceso al código de corrección ($c_{new}$) durante la generación.

1. Arquitectura de la Tubería

El flujo de trabajo consta de cuatro componentes principales:

• Localizador: Identifica "funciones focales" (probables de ser modificadas) y pruebas de regresión relacionadas. A diferencia de la versión en Python, que separaba estas tareas, la versión en Java las fusiona en un solo paso para manejar la mayor frecuencia de archivos de prueba nuevos en proyectos de Java. Utiliza un proceso de tres pasos con LLM: seleccionar archivos relevantes por nombre, seleccionar funciones por nombre y, finalmente, filtrar basándose en los cuerpos de las funciones.
• Contextualizador: Construye la estructura necesaria para un nuevo archivo de prueba, lo cual es común en Java. Determina el nombre del paquete correcto, las importaciones y la ruta del archivo consultando el repositorio y seleccionando entre opciones existentes para minimizar las alucinaciones.
• Generador de Prueba Inicial: Genera un candidato de prueba inicial ($t_{ot}$) como una nueva clase en un nuevo archivo, solicitado con la descripción del problema y el contexto localizado.
• Refinador: Mejora iterativamente la prueba utilizando retroalimentación de ejecución. Ejecuta la prueba en el código antiguo ($c_{old}$), analiza los registros mediante un crítico basado en LLM y reescribe la prueba si falla por la razón incorrecta. Este bucle se ejecuta hasta 10 veces, acumulando cambios para prevenir errores repetitivos.

2. Escalado de Inferencia mediante Solicitud Heterogénea

Para aumentar la diversidad de candidatos de prueba, el sistema emplea solicitud heterogénea en lugar de muestreo basado en temperatura. La descripción del problema se reescribe en seis variantes distintas (morphs):

• Estándar: Reescritura en un formato estructurado.
• Simple: Eliminación de jerga y simplificación del texto.
• dropCode: Eliminación de fragmentos de código potencialmente engañosos.
• initTest: Incorporación de una prueba inicial generada en la solicitud.
• initPatch: Incorporación de un parche de código sugerido en la solicitud.
• Predeterminado: Uso de la descripción original del problema.

Un Selector de Pruebas evalúa luego los seis candidatos resultantes (junto con sus registros de ejecución) y selecciona la única mejor prueba para su envío.

Contribuciones Clave

1. TDD-Bench-Java: El primer punto de referencia a nivel de repositorio específicamente para la generación de pruebas de reproducción en Java. Comprende 250 instancias obtenidas de repositorios de código abierto populares (por ejemplo, Trino, Jackson, RocketMQ), filtradas para asegurar un comportamiento de "fallar-a-pasar". El conjunto de datos incluye diversas herramientas de compilación (Maven, Gradle) y estructuras de proyecto.
2. e-Otter++ para Java: Una solución robusta adaptada de flujos de trabajo en Python, que logra un alto rendimiento en el nuevo punto de referencia. Es la primera solución completa para la generación de pruebas de reproducción de Java a nivel de repositorio que incluye localización de fallos.
3. Evaluación Industrial Propietaria: El artículo evalúa el sistema en un conjunto de datos propietario libre de contaminación de 150 problemas de un proyecto interno de IBM en Java. Esto proporciona información sobre los desafíos de aplicar estos modelos a código empresarial del mundo real, que a menudo difiere significativamente de los datos de código abierto.

Resultados

Punto de Referencia Público (TDD-Bench-Java)

Utilizando los modelos Claude-Sonnet-4.5 y GPT-5.2, e-Otter++ logró:

• 43.6% de tasa de fallar-a-pasar con Claude-Sonnet-4.5.
• 46.4% de tasa de fallar-a-pasar con GPT-5.2.

Hallazgos Clave:

• Impacto del Refinamiento: El paso de refinamiento (e-Otter) mejoró significativamente el rendimiento sobre el generador inicial (Otter), con mejoras relativas que oscilan entre el 26.2% y el 64.3% dependiendo del modelo y el morph.
• Solicitud Heterogénea: El uso de seis morphs aumentó la tasa de fallar-a-pasar en N=6 (al menos un candidato tiene éxito) en más del 32% en comparación con los enfoques de variante única.
• Significancia Estadística: Las pruebas de McNemar confirmaron que las mejoras de Otter a e-Otter fueron estadísticamente significativas ($p < 0.01$).

Resultados del Conjunto de Datos Propietario

El rendimiento en el conjunto de datos interno de IBM fue menor, destacando la dificultad del código empresarial:

• Rendimiento Predeterminado: Con descripciones de problemas predeterminadas, la tasa de fallar-a-pasar fue solo del 4% (6/150).
• Con Pistas: Cuando se proporcionaron "pistas" al sistema (nuevos nombres de clases y firmas de funciones derivadas del parche de código), la tasa mejoró al 20% (30/150).
• Características de los Datos: Los problemas propietarios eran más cortos, carecían de fragmentos de código e involucraban parches de código significativamente más grandes (promedio de 362 líneas frente a 55 líneas en datos públicos). Además, el 84% de los problemas propietarios eran solicitudes de características en lugar de correcciones de errores, a menudo introduciendo archivos nuevos que los modelos tienen dificultades para anticipar.

Significado y Afirmaciones

El artículo afirma hacer una contribución significativa al campo mediante:

1. Cerrar la Brecha Lingüística: Proporcionar el primer punto de referencia y solución dedicados para Java, un lenguaje crítico para el software empresarial pero previamente descuidado en la investigación de generación de pruebas de reproducción.
2. Relevancia Industrial: Ir más allá de los puntos de referencia de código abierto para evaluar el rendimiento en datos propietarios, revelando que, aunque los modelos funcionan bien con datos públicos curados, enfrentan desafíos sustanciales con el "ruido" y la complejidad de los problemas empresariales del mundo real (por ejemplo, descripciones cortas, generación de nuevos archivos).
3. Rigor Metodológico: Demostrar que el escalado de inferencia mediante solicitud heterogénea y refinamiento impulsado por ejecución son estrategias efectivas para Java, incluso cuando el sistema de tipos estático introduce errores en tiempo de compilación que difieren de los errores en tiempo de ejecución de Python.

Los autores concluyen que, aunque los enfoques actuales basados en LLM muestran promesa, llevar un diagnóstico y validación confiables al desarrollo de software en Java requiere mayor innovación, particularmente en el manejo de problemas mal especificados y la generación de contexto preciso para nuevas estructuras de código.