💻 computer science

Hallucination to Consensus: Multi-Agent LLMs for End-to-End JUnit Test Generation

El artículo presenta CANDOR, un marco innovador basado en ingeniería de prompts y múltiples agentes de LLM que utiliza un mecanismo de consenso para generar pruebas unitarias JUnit en Java con una corrección de oráculos y puntuaciones de mutación superiores a los métodos actuales como EvoSuite y TOGLL.

Autores originales: Qinghua Xu, Guancheng Wang, Lionel Briand, Kui Liu

Publicado 2026-03-27

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Qinghua Xu, Guancheng Wang, Lionel Briand, Kui Liu

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

¡Claro que sí! Imagina que escribir pruebas para un programa informático es como preparar una inspección de seguridad para un nuevo edificio antes de que la gente pueda vivir en él.

Aquí tienes la explicación de este paper (documento de investigación) sobre CANDOR, contada de forma sencilla y con analogías divertidas:

🏗️ El Problema: Construir sin planos

En el mundo del software (especialmente en Java), los programadores necesitan escribir "pruebas unitarias". Piensa en esto como si fueran inspecciones de seguridad para cada habitación del edificio.

El problema: Hacer estas inspecciones a mano es muy lento y aburrido.
La solución vieja: Antes usábamos robots automáticos (como EvoSuite) que lanzaban pelotas de tenis contra las paredes para ver si se rompían. Funcionaba bien para ver cuántas paredes tocaban (cobertura), pero no entendían por qué la pared debía aguantar o si el diseño era correcto.
La solución nueva (y problemática): Luego llegaron los Inteligencias Artificiales (IA) modernas. Son como arquitectos muy inteligentes que leen los planos en lenguaje natural. Pero tienen un defecto: a veces alucinan. Es decir, inventan cosas que no existen o se confunden, diciendo "la puerta es azul" cuando en el plano dice "roja". Además, para que funcionen bien, a veces hay que entrenarlas con miles de libros (lo cual es caro y lento).

🚀 La Solución: CANDOR (El Equipo de Expertos)

Los autores crearon CANDOR, que no es un solo robot, sino un equipo de especialistas que trabajan juntos. En lugar de confiar en una sola IA, usan un sistema de "mesa redonda" para evitar errores.

Imagina que CANDOR es una empresa de construcción de pruebas con estos empleados:

El Iniciador (Initializer): Es el albañil que pone los ladrillos básicos. Si comete un error de sintaxis (como poner un ladrillo al revés), lo corrige hasta que la estructura es sólida.
El Planificador (Planner): Es el jefe de obra. Mira qué partes del edificio aún no han sido inspeccionadas y dice: "¡Oye, nadie ha revisado la ventana del ático! Vamos a crear una prueba para eso".
El Probador (Tester): Es quien ejecuta las pruebas. Escribe el código para verificar si la ventana aguanta el viento.
El Inspector: Revisa si el código del probador funciona o si hay errores de compilación (como olvidar poner un tornillo).

🧠 El Gran Truco: La "Mesa Redonda" (Panel de Discusión)

Aquí está la parte más genial. A veces, el código del edificio tiene un error oculto (un bug). Si la IA lee ese código con error, podría decir: "¡Todo está bien!" cuando en realidad debería fallar.

Para evitar esto, CANDOR usa una Mesa Redonda de Expertos:

Imagina que tienes a 3 expertos (llamados Panelistas) que son muy inteligentes pero a veces se confunden y piensan demasiado (se vuelven "paranoicos" o overthinking).
Estos expertos discuten entre sí: "¿Crees que la puerta debe abrirse hacia adentro?".
Uno dice: "Sí, porque el plano dice así". Otro dice: "Espera, pero si hay un incendio, debería abrirse hacia afuera".
Luego, un Curador (el moderador) escucha todas las opiniones, filtra el ruido y decide cuál es la respuesta correcta basándose en el consenso.

La analogía: Es como cuando tienes una duda en un examen y le preguntas a tres amigos. Si dos dicen "A" y uno dice "B", y el tercero explica por qué "B" es imposible, el moderador elige "A". Esto evita que la IA invente respuestas locas (alucinaciones).

🛠️ El Problema de la "Paranoia" (Overthinking)

Los expertos más inteligentes (los modelos de razonamiento) a veces piensan tanto que escriben libros enteros para decir "2 + 2 = 4".

Solución de CANDOR: Tienen un traductor rápido (el Interpreter). Este traductor escucha al experto paranoico, ignora sus dudas y miedos, y extrae solo la conclusión clara y concisa. Es como tener a un amigo que te resume la película de 3 horas en 5 minutos sin perder la esencia.

🏆 Los Resultados: ¿Funciona?

Los autores probaron CANDOR en dos tipos de edificios:

Edificios simples (HumanEvalJava): Pruebas estándar.
Edificios complejos (LeetCode): Problemas difíciles de programación.

Los hallazgos:

Cobertura: CANDOR encontró tantos "puntos débiles" en el código como los robots antiguos (EvoSuite), pero escribió las pruebas de forma más humana y legible.
Detección de errores: ¡CANDOR encontró muchos más errores reales que los robots viejos! (Mejoró la "puntuación de mutación" en más de un 4%).
Precisión: ¡Aquí es donde brilla! CANDOR fue mucho mejor (más del 21% mejor) que el mejor sistema anterior (TOGLL) para decir si el código hacía lo que debía hacer, incluso cuando el código tenía errores. Y lo hizo sin necesidad de entrenar a la IA con miles de libros, usando solo instrucciones inteligentes.

💡 En Resumen

CANDOR es como pasar de tener un solo inspector de obras (que a veces se equivoca o inventa cosas) a tener un equipo completo donde:

Uno planifica.
Otro ejecuta.
Unos expertos discuten para asegurar que no hay errores.
Un moderador toma la decisión final.

Todo esto se hace sin gastar una fortuna en entrenar a la IA, logrando que las pruebas de software sean más seguras, precisas y fáciles de entender para los humanos. ¡Es como tener un equipo de arquitectos de élite trabajando en tu código las 24 horas!

Resumen Técnico: CANDOR

1. El Problema

La generación automática de pruebas unitarias es un desafío crítico en la ingeniería de software, especialmente en lenguajes fuertemente tipados como Java.

Limitaciones de los métodos tradicionales: Herramientas basadas en búsqueda (como EvoSuite) o algoritmos aleatorios logran una alta cobertura de código, pero a menudo generan prefijos de prueba poco legibles y oráculos de regresión (assertions derivadas del comportamiento actual del código). Si el código original tiene errores, estos oráculos replican el error en lugar de detectar la falla.
Limitaciones de los LLMs actuales: Aunque los Modelos de Lenguaje Grande (LLMs) pueden generar oráculos basados en especificaciones (descripciones en lenguaje natural), los enfoques existentes sufren de:
- Alucinaciones: Generación de afirmaciones incorrectas o inconsistentes.
- Dependencia de herramientas externas: Muchos métodos requieren que EvoSuite genere la estructura de la prueba primero, heredando sus limitaciones.
- Costo de ajuste (Fine-tuning): Los mejores enfoques actuales (como TOGLL) requieren un ajuste fino costoso en conjuntos de datos específicos, lo que los hace poco flexibles para nuevos entornos o versiones de Java.
- Sobrerazonamiento: Los LLMs con capacidades de razonamiento tienden a ser excesivamente verbosos y redundantes, aumentando el tiempo y costo de generación.

2. Metodología: El Framework CANDOR

Los autores proponen CANDOR, un marco de trabajo end-to-end basado en ingeniería de prompts (sin ajuste fino) que utiliza una arquitectura de múltiples agentes LLM especializados para generar pruebas JUnit completas (prefijos y oráculos).

El proceso se divide en tres etapas principales:

Etapa I: Inicialización
- Un agente Initializer genera un archivo de prueba inicial basado en el código fuente.
- Un proceso de Validación compila y ejecuta el código. Si hay errores de sintaxis, se retroalimentan al generador para corregirlos hasta obtener un archivo sintácticamente válido ( $v_1$ ).
Etapa II: Generación de Prefijos de Prueba
- Se utiliza un bucle iterativo con tres agentes:
  - Planner: Analiza los huecos en la cobertura de código (usando Jacoco) y diseña un plan para nuevos casos de prueba.
  - Tester: Genera el código Java real basado en el plan del Planner.
  - Inspector: Detecta errores de compilación o ejecución y proporciona retroalimentación al Tester.
- El resultado es un archivo de prueba con alta cobertura ( $v_2$ ), pero con oráculos tentativos que pueden ser incorrectos si el código fuente tiene errores.
Etapa III: Corrección de Oráculos (El núcleo de la innovación)
- Para garantizar que los oráculos reflejen la intención real (descrita en los comentarios/docstrings) y no el comportamiento erróneo del código, CANDOR introduce una estrategia de "Discusión de Panel":
  1. Requirement Engineer: Extrae requisitos y especificaciones formales (lógica de predicados) de la descripción natural del código.
  2. Panelistas (LLMs de Razonamiento): Múltiples agentes independientes (ej. DeepSeek R1) evalúan los oráculos tentativos contra las especificaciones extraídas.
  3. Interpretes (LLMs Básicos): Para mitigar el "sobrerazonamiento" (outputs excesivamente largos), un agente básico extrae y estructura las ideas clave de los Panelistas.
  4. Curador: Un agente finaliza el proceso agregando los juicios de los Panelistas. En lugar de una votación simple, el Curador analiza la lógica de los argumentos para llegar a un consenso sobre el oráculo correcto, corrigiendo alucinaciones individuales.

3. Contribuciones Clave

Primera arquitectura Multi-Agente para Java: CANDOR es el primer framework que utiliza agentes LLM of-the-shelf (sin fine-tuning) para la generación end-to-end de pruebas JUnit, eliminando la dependencia de herramientas como EvoSuite para la estructura inicial.
Estrategia de Consenso para Oráculos: La introducción de la "discusión de panel" mitiga eficazmente las alucinaciones de los LLMs, logrando oráculos basados en especificaciones mucho más precisos.
Pipeline Dual-LLM: Una solución innovadora para manejar la verbosidad de los modelos de razonamiento, utilizando un agente básico para sintetizar las conclusiones de un agente de razonamiento, mejorando la eficiencia.
Independencia de Entorno: Al no requerir ajuste fino, CANDOR es adaptable a nuevas versiones de Java y entornos de construcción sin necesidad de recolectar nuevos conjuntos de datos.

4. Resultados Experimentales

Los autores evaluaron CANDOR en dos conjuntos de datos: HumanEvalJava y un nuevo conjunto LeetCodeJava (con problemas de dificultad media y alta). Se comparó contra EvoSuite, LLM-Empirical y TOGLL (el estado del arte en ajuste fino).

Calidad de los Prefijos de Prueba (Cobertura):
- CANDOR es comparable a EvoSuite en cobertura de líneas y ramas (ambos superan el 98% en la mayoría de los casos).
- CANDOR supera significativamente a los enfoques puramente basados en prompts (LLM-Empirical).
Calidad de los Oráculos (Puntuación de Mutación):
- CANDOR supera claramente a EvoSuite en puntuación de mutación (capacidad de detectar errores), con mejoras de más de 0.049 en todos los conjuntos de datos. Esto demuestra que los prefijos generados por LLM son semánticamente más ricos.
Precisión de Oráculos (Corrección):
- En código correcto y defectuoso, CANDOR supera a TOGLL (que requiere ajuste fino) en al menos 21.1 puntos porcentuales en precisión de oráculos.
- Esto es notable porque CANDOR usa modelos genéricos, mientras que TOGLL usa modelos ajustados específicamente.
Estudios de Ablación:
- Eliminar el agente Planner reduce drásticamente la cobertura.
- Eliminar la discusión de panel reduce la precisión de los oráculos en más de 0.06, confirmando que el consenso es vital para la corrección.

5. Significado e Impacto

Este trabajo representa un avance significativo en la automatización de pruebas de software:

Viabilidad Práctica: Demuestra que se pueden generar pruebas de alta calidad sin los costos prohibitivos del ajuste fino (fine-tuning) ni la rigidez de herramientas de búsqueda tradicionales.
Robustez ante Errores: A diferencia de los oráculos de regresión, CANDOR es capaz de detectar errores en el código fuente al basar sus afirmaciones en la descripción natural del comportamiento esperado, no en el comportamiento actual.
Nueva Dirección de Investigación: Establece un nuevo paradigma para la generación de pruebas utilizando arquitecturas multi-agente colaborativas, donde la "discusión" y el "consenso" son mecanismos técnicos para mejorar la fiabilidad de la IA.

En conclusión, CANDOR cierra la brecha entre la cobertura de código (donde dominan las herramientas tradicionales) y la corrección semántica de las pruebas (donde dominan los LLMs), ofreciendo una solución robusta, flexible y de alto rendimiento para la industria del software.