💻 computer science

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

O artigo apresenta o CANDOR, um novo framework baseado em engenharia de prompts que utiliza múltiplos agentes de LLM colaborando por consenso para gerar testes unitários JUnit em Java com maior precisão nos oráculos e desempenho superior em relação aos métodos atuais.

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

Publicado 2026-03-27

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

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

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é um gerente de uma fábrica de software. Sua equipe de programadores cria códigos complexos, mas, para garantir que tudo funcione perfeitamente, eles precisam escrever "testes de qualidade". Esses testes são como uma lista de verificação: eles verificam se o produto final faz exatamente o que deveria fazer.

O problema é que escrever esses testes manualmente é chato, demorado e caro. Por isso, a indústria tenta usar robôs (algoritmos) para fazer isso. Mas os robôs antigos eram como crianças teimosas: eles conseguiam cobrir muitas partes da fábrica (o código), mas muitas vezes não entendiam o que estavam testando, apenas repetiam o que já existiam.

Aqui entra o CANDOR, o novo "super-robô" apresentado neste artigo. Vamos entender como ele funciona usando uma analogia de uma Comissão de Especialistas.

O Problema: A Alucinação do Robô

Antes do CANDOR, os robôs de teste (baseados em Inteligência Artificial) tinham um defeito grave: a "alucinação". Imagine um robô que, ao tentar explicar como um produto deve funcionar, começa a inventar fatos. Ele diz: "O produto deve ser azul", quando na verdade a instrução dizia "vermelho". No mundo do código, isso significa que o teste passa, mas o produto está errado.

Além disso, muitos robôs precisavam ser "treinados" com milhões de exemplos específicos (o que é caro e difícil) ou dependiam de ferramentas antigas que não funcionavam bem com tecnologias novas.

A Solução: O CANDOR (A Comissão de Especialistas)

O CANDOR não é um único robô. É uma equipe de especialistas trabalhando juntos, como se fosse um painel de juízes em um programa de TV ou uma reunião de conselho. Eles não precisam ser treinados com dados extras; eles já são inteligentes e apenas recebem instruções claras.

Aqui está como essa "equipe" trabalha, passo a passo:

1. O Arquiteto e o Construtor (Geração do Teste)

Primeiro, o CANDOR precisa criar o esqueleto do teste (a parte que executa o código).

O Inicializador: Começa a construir o teste, mas pode errar a gramática (como usar vírgulas onde deveria usar ponto e vírgula).
O Inspetor: É como um fiscal de obras. Ele olha o que foi construído e diz: "Ei, faltou um parafuso aqui" ou "Isso não compila".
O Planejador: É o estrategista. Ele olha para o código e diz: "Nós testamos a porta da frente, mas esquecemos da janela de trás. Vamos criar um teste para a janela."
O Testador: Executa o plano do Planejador e escreve o código do teste.

Esses agentes trabalham em loop, corrigindo erros e adicionando mais testes até cobrir quase todo o código.

2. O Grande Desafio: O "Oráculo" (A Resposta Correta)

A parte mais difícil não é criar o teste, é saber qual é a resposta certa. Isso é chamado de "Oráculo".

Exemplo: Se você pede para o código somar dois números, o teste deve verificar se o resultado é 2+2=4. Se o código tem um erro e dá 5, o teste precisa gritar "ERRO!".
O problema é que, se o código original já tiver um erro, o robô pode achar que o erro é a resposta certa!

3. A Grande Ideia: O Painel de Discussão (Consenso)

Aqui está a mágica do CANDOR para evitar alucinações. Em vez de confiar em um único robô para decidir a resposta certa, o CANDOR convoca um Painel de Especialistas:

Os Painelistas (Especialistas Raciocinadores): Vários robôs inteligentes leem a descrição do que o programa deveria fazer (em linguagem humana) e discutem entre si: "Ei, acho que a resposta deve ser 147, não 27. Veja o porquê..."
O Tradutor (Interpretador): Os robôs inteligentes às vezes "pensam demais" e falam 10.000 palavras para dizer uma coisa simples. O Tradutor é um robô mais rápido que resume o pensamento deles em uma frase clara.
O Curador (O Juiz Final): Ele ouve todos os Painelistas e Tradutores. Se 2 de 3 dizem que a resposta é 147 e explicam o porquê, o Curador decide: "Ok, a resposta é 147".

Isso cria um consenso. Se um robô alucinar e inventar uma resposta, os outros corrigem. É como ter três amigos verificando uma conta de matemática: se um erra, os outros dois apontam o erro.

Por que isso é incrível?

Os autores testaram o CANDOR em dois cenários:

Códigos perfeitos: O CANDOR foi tão bom quanto os melhores robôs antigos em cobrir o código, mas muito melhor em encontrar erros sutis.
Códigos com defeitos (Bugs): Quando o código original tinha erros, os robôs antigos (que olhavam apenas para o código) criavam testes que aceitavam o erro como normal. O CANDOR, olhando para a descrição humana do que deveria acontecer, percebeu o erro e criou um teste que o rejeitou.

O resultado? O CANDOR foi 21% melhor que o melhor concorrente atual (que usa treinamento pesado e caro) em criar testes que realmente funcionam.

Resumo em uma frase

O CANDOR é como substituir um único funcionário cansado e propenso a erros por uma equipe de especialistas que discute, debate e chega a um consenso, garantindo que o software não apenas funcione, mas faça exatamente o que o cliente pediu.

Título: Hallucination to Consensus: Multi-Agent LLMs para Geração de Testes JUnit de Ponta a Ponta

1. O Problema

A geração automática de testes unitários é crucial para garantir a correção do software, mas a escrita manual é intensiva em mão de obra. As abordagens tradicionais (baseadas em busca ou algoritmos aleatórios, como o EvoSuite) focam principalmente na geração de prefixos de teste (código que executa o método) para maximizar a cobertura de código. No entanto, elas frequentemente falham em gerar oráculos de teste (asserções que verificam o comportamento esperado) precisos, dependendo de "oráculos de regressão" que apenas replicam o comportamento atual do código (assumindo que o código atual está correto).

As soluções baseadas em Grandes Modelos de Linguagem (LLMs) recentes tentam gerar oráculos baseados em especificações (descrições em linguagem natural), mas enfrentam desafios significativos:

Alucinação: LLMs tendem a gerar oráculos incorretos ou inconsistentes.
Dependência de Ferramentas Externas: Muitos métodos dependem do EvoSuite para gerar o esqueleto do teste, o que limita a legibilidade e a adaptação a novas versões do Java.
Custo de Ajuste Fino (Fine-tuning): As melhores abordagens atuais (como o TOGLL) exigem ajuste fino em grandes conjuntos de dados específicos, o que é custoso e pouco generalizável.
Verbosidade: LLMs com capacidades de raciocínio tendem a produzir saídas excessivamente longas e redundantes ("fenômeno de superpensamento"), dificultando a extração de resultados concisos.

2. Metodologia: O Framework CANDOR

O artigo propõe o CANDOR, um framework inovador de ponta a ponta para geração de testes JUnit em Java, utilizando apenas LLMs prontos para uso (off-the-shelf) e uma arquitetura de agentes múltiplos coordenados. O processo é dividido em três etapas principais:

Etapa I: Inicialização

Um agente Initializer gera um arquivo de teste inicial sintaticamente correto a partir do código-fonte.
Um processo de Validação compila e executa o teste. Se houver erros de sintaxe, o feedback é enviado de volta ao Initializer para correção iterativa até que um arquivo válido ( $v_1$ ) seja produzido.

Etapa II: Geração de Prefixos de Teste

Foca em aumentar a cobertura de código.
Planner: Analisa as lacunas de cobertura e propõe novos casos de teste.
Tester: Gera o código Java executável baseado no plano.
Inspector: Verifica erros de compilação ou execução e fornece feedback para refinar o código.
Nota: Nesta etapa, os oráculos são gerados diretamente do código-fonte (que pode conter bugs), resultando em "oráculos tentativos" que podem estar incorretos.

Etapa III: Correção de Oráculos (O Núcleo da Inovação)
Esta etapa visa corrigir oráculos tentativos usando a descrição natural do software, independentemente de bugs no código-fonte.

Requirement Engineer: Extrai requisitos e especificações formais (lógica de predicados) a partir da descrição em linguagem natural do método.
Painel de Discussão (Panel Discussion): Inspirado na ideia de que "a verdade surge entre amigos", múltiplos agentes Panelist (usando LLMs de raciocínio, como o DeepSeek R1) avaliam independentemente os oráculos tentativos contra os requisitos extraídos.
Pipeline Dual-LLM: Para mitigar a verbosidade dos LLMs de raciocínio, cada Panelist é acompanhado por um agente Interpreter (LLM básico) que extrai e estrutura as conclusões chave das longas reflexões do Panelist.
Curator: Um agente final agrega os julgamentos de todos os pipelines, analisa o consenso e as justificativas lógicas para determinar o oráculo final correto, corrigindo alucinações individuais.

3. Principais Contribuições

Primeiro Framework Multi-Agente End-to-End: O CANDOR é a primeira abordagem para geração de testes JUnit em Java que utiliza exclusivamente LLMs prontos para uso, sem necessidade de ajuste fino (fine-tuning) ou dependência de ferramentas externas como o EvoSuite para a geração completa.
Estratégia de Consenso para Mitigar Alucinações: A introdução de um mecanismo de "painel de discussão" onde múltiplos agentes de raciocínio debatem e validam oráculos, alcançando um consenso preciso.
Pipeline Dual-LLM: Uma solução técnica para o problema da verbosidade, onde um LLM de raciocínio gera o pensamento e um LLM básico o resume, garantindo eficiência e precisão.
Independência de Assinaturas de Método: Diferente do TOGLL, que depende de assinaturas de método (muitas vezes ausentes), o CANDOR utiliza apenas descrições em linguagem natural, tornando-o mais robusto para cenários do mundo real.

4. Resultados Experimentais

Os experimentos foram realizados nos conjuntos de dados HumanEvalJava e LeetCodeJava (incluindo versões com código defeituoso injetado via PiTest).

Qualidade dos Prefixos de Teste (Cobertura):
- O CANDOR alcançou cobertura de linhas e ramos comparável ao EvoSuite (o estado da arte em cobertura), com diferenças estatisticamente insignificantes.
- Superou significativamente abordagens puramente baseadas em prompt (LLM-Empirical).
Qualidade dos Oráculos (Correção):
- O CANDOR superou o TOGLL (o atual estado da arte baseado em ajuste fino) em pelo menos 21,1 pontos percentuais na correção dos oráculos, tanto em código correto quanto em código defeituoso.
- Isso é notável porque o CANDOR usa LLMs genéricos, enquanto o TOGLL usa modelos ajustados especificamente para a tarefa.
Pontuação de Mutação (Detecção de Bugs):
- O CANDOR obteve pontuações de mutação significativamente superiores ao EvoSuite e ao LLM-Empirical em todos os conjuntos de dados. Isso indica que os testes gerados pelo CANDOR são mais eficazes em detectar falhas comportamentais sutis, graças à compreensão semântica dos LLMs.
Estudo de Ablação:
- Remover o agente Planner reduziu drasticamente a cobertura de código.
- Remover a Discussão de Painel causou uma queda significativa na correção dos oráculos, confirmando que o consenso entre múltiplos agentes é vital para a precisão.

5. Significância e Conclusão

O trabalho CANDOR representa um avanço significativo na automação de testes de software. Ele demonstra que é possível superar as limitações das ferramentas tradicionais de busca e dos modelos de ajuste fino caros, utilizando uma arquitetura inteligente de agentes colaborativos.

Impacto Prático: Oferece uma solução flexível que se adapta a novas versões do Java e ambientes de desenvolvimento sem a necessidade de re-treinamento de modelos.
Confiabilidade: A estratégia de "Hallucination to Consensus" (Alucinação para Consenso) resolve um dos maiores obstáculos na aplicação de LLMs para tarefas críticas de engenharia de software: a confiabilidade do output.
Futuro: O framework estabelece uma base para a geração de testes em nível de projeto, com potencial para lidar com dependências complexas através da adição de agentes especializados.

Em resumo, o CANDOR prova que a colaboração entre agentes de IA especializados, combinada com mecanismos de verificação cruzada, pode gerar testes unitários de alta qualidade, com oráculos precisos baseados em especificações, superando as abordagens atuais mais sofisticadas.