Resumen Técnico: MocklessTester

Enunciado del Problema

Aunque los Modelos de Lenguaje Grande (LLM) han demostrado potencial para la generación automatizada de pruebas, los enfoques existentes para Java dependen principalmente de frameworks de simulación (por ejemplo, Mockito) para aislar el método bajo prueba (MUT) de sus dependencias. Esta dependencia introduce dos limitaciones fundamentales:

1. Cobertura superficial: Las pruebas simuladas ejercitan el MUT de forma aislada, dejando sin probar el comportamiento real de las clases de dependencia.
2. Fragilidad de la simulación: Las pruebas se acoplan estrechamente a comportamientos de API asumidos, rompiéndose cuando las dependencias evolucionan, incluso si el comportamiento real permanece compatible.

Las pruebas sin simulación (mockless), que instancian y ejecutan dependencias reales, ofrecen una solución pero enfrentan desafíos significativos. Generar pruebas sin simulación válidas requiere una adhesión estricta a las restricciones del lenguaje, una instanciación correcta de objetos y secuencias válidas de llamadas a API. Los enfoques actuales basados en LLM luchan aquí debido a dos causas raíz de las alucinaciones:

• No saber: El LLM carece de contexto específico del proyecto suficiente (por ejemplo, constructores válidos, métodos de fábrica o patrones de uso) para generar código correcto.
• No seguir: Incluso cuando se proporcionan restricciones, el LLM no cumple con ellas (por ejemplo, violando la validez de símbolos o protocolos de llamadas a API), a menudo debido a la falta de mecanismos de aplicación.

Metodología: MocklessTester

Los autores proponen MocklessTester, un enfoque de generación de pruebas unitarias sin simulación para Java que emplea un flujo de trabajo iterativo planificar-generar-validar-arreglar. El sistema se basa en dos estrategias centrales para abordar las causas raíz identificadas: Generación enriquecida con contexto y Arreglo con restricciones aplicadas.

1. Fase de Preparación

Antes de comenzar la generación de pruebas, MocklessTester analiza el repositorio objetivo para construir tres artefactos específicos del proyecto:

• Grafo de Propiedades de Código (CPG): Construido utilizando Joern, este grafo captura el uso de dependencias, permitiendo la recuperación de ejemplos reales de construcción de objetos y llamadas a API mediante segmentación de programas.
• ClassIndex: Un registro de todas las clases, métodos, constructores e importaciones visibles en el proyecto. Sirve como verdad fundamental para validar símbolos y resolver tipos durante la reparación.
• Modelo de Estado de Tipo Markoviano: Un modelo probabilístico que captura órdenes válidos de llamadas a métodos para APIs con estado. Se inicializa a partir de evidencia del código fuente y se actualiza dinámicamente en función de los resultados de las pruebas para detectar secuencias de llamadas ilegales.

2. Bucle Iterativo Multiagente

El proceso de generación involucra cinco agentes: Inicializador, Planificador, Generador, Validador y Arreglador.

• Generación enriquecida con contexto: Para mitigar el "No saber", el Generador no depende únicamente del código fuente de la Clase bajo Prueba (CUT). En su lugar, un segmentador de programas extrae patrones reales de instanciación y uso de dependencias del código de producción y de pruebas del proyecto. Estos patrones se inyectan en el prompt para guiar al LLM en la creación de instanciaciones de objetos plausibles.
• Arreglo con restricciones aplicadas: Para mitigar el "No seguir", el Arreglador emplea un mecanismo de reparación de dos etapas para las pruebas fallidas:
  • Etapa I (Arreglador I): Genera una reparación inicial basada en la retroalimentación de ejecución (errores de compilación/ejecución).
  • Etapa II (Arreglador II): Si la reparación inicial viola las restricciones, se activa una segunda reparación. El LLM debe generar una reparación que satisfaga tres niveles de restricciones y proporcionar una justificación estructurada que explique cómo la reparación resuelve el fallo y se adhiere a las reglas:
    • Nivel de símbolo: Asegura que todas las clases, métodos e importaciones existan en el ClassIndex.
    • Nivel de protocolo: Asegura que las secuencias de llamadas a API respeten el modelo de estado de tipo Markoviano (por ejemplo, inicializando el estado antes del uso).
    • Nivel de iteración: Aprovecha la Memoria de Experiencia, que almacena patrones de reparación exitosos ("pruebas de oro"), recetas de reparación y anti-patrones para evitar repetir fallos conocidos.

Contribuciones Clave

1. Prompting enriquecido con contexto: Los autores identifican los patrones de uso de dependencias como contexto crítico. Proponen una estrategia que aumenta al LLM con ejemplos reales de instanciación de dependencias extraídos del proyecto objetivo, reduciendo significativamente las alucinaciones causadas por el conocimiento insuficiente.
2. Mecanismo de arreglo con restricciones aplicadas: Un novedoso proceso de reparación de dos etapas que aplica restricciones a nivel de símbolo, protocolo e iteración. Crucialmente, la segunda etapa requiere que el modelo genere una justificación estructurada para sus correcciones, abordando directamente las alucinaciones de "no seguir".
3. Primera aproximación LLM sin simulación para Java: MocklessTester se presenta como el primer enfoque basado en LLM para Java que apunta explícitamente a dependencias externas, avanzando las pruebas automatizadas desde la prueba unitaria simulada hacia una ejecución realista.
4. Evaluación empírica exhaustiva: El estudio introduce la Cobertura de Líneas de Dependencia (DepLC) como una nueva métrica para medir la extensión del código real del proyecto ejercitado más allá de la Clase bajo Prueba (CUT).

Resultados Experimentales

El enfoque fue evaluado en Defects4J (14 proyectos, 130 clases) y en una nueva referencia, Deps4J (5 proyectos recientes de múltiples módulos, 30 clases), frente a la línea base de vanguardia PANTA.

• Efectividad:

  • En Defects4J, MocklessTester mejoró la cobertura de líneas promedio en un 19.99% (de 68.83% a 88.82%) y la cobertura de ramas en un 24.90% (de 58.84% a 83.74%). La puntuación de mutación aumentó un 13.67%.
  • En Deps4J, mejoró la cobertura de líneas en un 22.69% y la cobertura de ramas en un 15.78%, manteniendo puntuaciones de mutación comparables.
  • Cobertura de Dependencias: MocklessTester cubrió significativamente más código de dependencia real, aumentando la DepLC del proyecto en 378 líneas en Defects4J y 55 líneas en Deps4J en comparación con la línea base.
  • Eficiencia de las pruebas: A pesar de generar menos pruebas por proyecto en promedio, MocklessTester logró una mayor cobertura, indicando una mayor calidad por prueba.

• Eficiencia:

  • MocklessTester incurrió en costos totales de tokens y tiempo más altos debido a la realización de más iteraciones para alcanzar una mayor cobertura.
  • Sin embargo, el costo sigue siendo práctico: promediando 108.97 segundos y 26.59k tokens por método en Defects4J.
  • Cabe destacar que MocklessTester fue substancialmente más rápido por iteración (aproximadamente un 58% menos de tiempo) que la línea base, lo que sugiere que sus iteraciones son más eficientes en tiempo incluso si son más numerosas.

• Estudio de Ablación:

  • Eliminar la Recuperación de Uso causó la mayor caída en el rendimiento, confirmando la importancia del contexto.
  • Eliminar las restricciones a nivel de protocolo tuvo el segundo impacto más grande, destacando la dificultad de gestionar objetos con estado sin aplicación explícita.
  • Las restricciones a nivel de símbolo y de iteración también proporcionaron mejoras significativas, aunque ligeramente menores.

Significado y Afirmaciones

El artículo afirma que MocklessTester aborda con éxito las limitaciones de las pruebas basadas en simulación al permitir la generación de pruebas que ejercitan dependencias reales del proyecto. Al abordar sistemáticamente el "no saber" mediante el enriquecimiento de contexto y el "no seguir" mediante la aplicación de restricciones, el enfoque logra resultados de vanguardia en cobertura de líneas, cobertura de ramas y puntuación de mutación tanto en referencias establecidas como nuevas.

Los autores enfatizan que, aunque el enfoque requiere más recursos computacionales que los métodos de línea base, el intercambio produce pruebas que no solo son más completas en cobertura, sino también más robustas frente a la evolución de las dependencias. La introducción de DepLC proporciona una nueva dimensión para evaluar conjuntos de pruebas, avanzando más allá de la CUT para medir la ejecución real del sistema más amplio. El trabajo sugiere que las mejoras futuras podrían involucrar mecanismos de memoria más ricos y generación de entrada consciente de la gramática para componentes centrados en el analizador sintáctico.