Resumo Técnico: MocklessTester

Declaração do Problema

Embora os Modelos de Linguagem de Grande Escala (LLMs) tenham demonstrado potencial para a geração automatizada de testes, as abordagens existentes para Java dependem principalmente de frameworks de mock (por exemplo, Mockito) para isolar o método sob teste (MUT) de suas dependências. Essa dependência introduz duas limitações fundamentais:

1. Cobertura Superficial: Testes com mocks exercitam o MUT de forma isolada, deixando o comportamento real das classes de dependência não testado.
2. Fragilidade dos Mocks: Os testes tornam-se fortemente acoplados a comportamentos de API assumidos, quebrando quando as dependências evoluem, mesmo que o comportamento real permaneça compatível.

A testagem sem mocks, que instancia e executa dependências reais, oferece uma solução, mas enfrenta desafios significativos. Gerar testes válidos sem mocks exige adesão estrita a restrições de linguagem, instanciação correta de objetos e sequências válidas de chamadas de API. As abordagens atuais baseadas em LLMs lutam aqui devido a duas causas raízes de alucinação:

• Não Saber: O LLM carece de contexto específico do projeto suficiente (por exemplo, construtores válidos, métodos de fábrica ou padrões de uso) para gerar código correto.
• Não Seguir: Mesmo quando as restrições são fornecidas, o LLM falha em cumpri-las (por exemplo, violando a validade de símbolos ou protocolos de chamada de API), frequentemente devido à falta de mecanismos de aplicação.

Metodologia: MocklessTester

Os autores propõem o MocklessTester, uma abordagem de geração de testes unitários sem mocks para Java que emprega um fluxo de trabalho iterativo planejar–gerar–validar–corrigir. O sistema é construído em torno de duas estratégias centrais para abordar as causas raízes identificadas: Geração Enriquecida com Contexto e Correção com Restrições Aplicadas.

1. Fase de Preparação

Antes do início da geração de testes, o MocklessTester analisa o repositório alvo para construir três artefatos específicos do projeto:

• Grafo de Propriedades de Código (CPG): Construído usando Joern, este grafo captura o uso de dependências, permitindo a recuperação de exemplos reais de construção de objetos e chamadas de API via fatiamento de programa.
• ClassIndex: Um registro de todas as classes, métodos, construtores e imports visíveis no projeto. Serve como verdade fundamental para validar símbolos e resolver tipos durante a reparação.
• Modelo de Estado de Tipo Markoviano: Um modelo probabilístico que captura ordens válidas de chamadas de método para APIs com estado. É inicializado a partir de evidências do código-fonte e atualizado dinamicamente com base nos resultados dos testes para detectar sequências de chamadas ilegais.

2. Loop Iterativo Multi-Agente

O processo de geração envolve cinco agentes: Inicializador, Planejador, Gerador, Validador e Corretor.

• Geração Enriquecida com Contexto: Para mitigar o "Não Saber", o Gerador não depende exclusivamente do código-fonte da Classe Sob Teste (CUT). Em vez disso, um fatiador de programa minera padrões reais de instanciação e uso de dependências do código de produção e de teste do projeto. Esses padrões são injetados no prompt para guiar o LLM na criação de instanciações de objetos plausíveis.
• Correção com Restrições Aplicadas: Para mitigar o "Não Seguir", o Corretor emprega um mecanismo de reparo em duas etapas para testes falhos:
  • Etapa I (Corretor I): Gera uma correção inicial com base no feedback de execução (erros de compilação/runtime).
  • Etapa II (Corretor II): Se a correção inicial violar restrições, um segundo reparo é acionado. O LLM deve gerar uma correção que satisfaça três níveis de restrições e fornecer uma justificativa estruturada explicando como a correção resolve a falha e aderir às regras:
    • Nível de Símbolo: Garante que todas as classes, métodos e imports existam no ClassIndex.
    • Nível de Protocolo: Garante que as sequências de chamadas de API respeitem o modelo de estado de tipo Markoviano (por exemplo, inicializando o estado antes do uso).
    • Nível de Iteração: Aproveita a Memória de Experiência, que armazena padrões de reparo bem-sucedidos ("testes de ouro"), receitas de correção e anti-padrões para evitar a repetição de falhas conhecidas.

Contribuições Principais

1. Prompting Enriquecido com Contexto: Os autores identificam padrões de uso de dependências como contexto crítico. Eles propõem uma estratégia que augmenta o LLM com exemplos reais de instanciação de dependências minerados do projeto alvo, reduzindo significativamente as alucinações causadas por conhecimento insuficiente.
2. Mecanismo de Correção com Restrições Aplicadas: Um processo de reparo em duas etapas que aplica restrições de nível de símbolo, protocolo e iteração. Crucialmente, a segunda etapa exige que o modelo gere uma justificativa estruturada para suas correções, visando diretamente as alucinações de "não seguir".
3. Primeira Abordagem LLM sem Mocks para Java: O MocklessTester é apresentado como a primeira abordagem baseada em LLM para Java que visa explicitamente dependências externas, avançando o teste automatizado de testes unitários com mocks para execução realista.
4. Avaliação Empírica Abrangente: O estudo introduz a Cobertura de Linha de Dependência (DepLC) como uma nova métrica para medir a extensão do código real do projeto exercitado além da Classe Sob Teste (CUT).

Resultados Experimentais

A abordagem foi avaliada no Defects4J (14 projetos, 130 classes) e em um novo benchmark, Deps4J (5 projetos recentes, multi-módulo, 30 classes), contra a linha de base state-of-the-art PANTA.

• Eficácia:

  • No Defects4J, o MocklessTester melhorou a cobertura de linha média em 19,99% (68,83% → 88,82%) e a cobertura de ramificação em 24,90% (58,84% → 83,74%). A pontuação de mutação aumentou em 13,67%.
  • No Deps4J, melhorou a cobertura de linha em 22,69% e a cobertura de ramificação em 15,78%, mantendo pontuações de mutação comparáveis.
  • Cobertura de Dependência: O MocklessTester cobriu significativamente mais código de dependência real, aumentando a DepLC do projeto em 378 linhas no Defects4J e 55 linhas no Deps4J em comparação com a linha de base.
  • Eficiência de Teste: Apesar de gerar menos testes por projeto em média, o MocklessTester alcançou maior cobertura, indicando maior qualidade por teste.

• Eficiência:

  • O MocklessTester incorreu em custos totais de tokens e tempo mais altos devido à realização de mais iterações para alcançar maior cobertura.
  • No entanto, o custo permanece prático: média de 108,97 segundos e 26,59k tokens por método no Defects4J.
  • Notavelmente, o MocklessTester foi substancialmente mais rápido por iteração (aproximadamente 58% menos tempo) do que a linha de base, sugerindo que suas iterações são mais eficientes em termos de tempo, mesmo sendo mais numerosas.

• Estudo de Ablação:

  • A remoção da Recuperação de Uso causou a maior queda de desempenho, confirmando a importância do contexto.
  • A remoção das restrições de nível de protocolo teve o segundo maior impacto, destacando a dificuldade de gerenciar objetos com estado sem aplicação explícita.
  • As restrições de nível de símbolo e de nível de iteração também forneceram melhorias significativas, embora ligeiramente menores.

Significado e Alegações

O artigo afirma que o MocklessTester aborda com sucesso as limitações dos testes baseados em mocks, permitindo a geração de testes que exercitam dependências reais do projeto. Ao abordar sistematicamente o "não saber" através do enriquecimento de contexto e o "não seguir" através da aplicação de restrições, a abordagem alcança resultados state-of-the-art em cobertura de linha, cobertura de ramificação e pontuação de mutação em benchmarks estabelecidos e novos.

Os autores enfatizam que, embora a abordagem exija recursos computacionais mais altos do que os métodos de linha de base, o trade-off produz testes que não são apenas mais abrangentes em cobertura, mas também mais robustos contra a evolução de dependências. A introdução da DepLC fornece uma nova dimensão para avaliar suites de testes, indo além da CUT para medir a execução real do sistema mais amplo. O trabalho sugere que melhorias futuras poderiam envolver mecanismos de memória mais ricos e geração de entrada consciente de gramática para componentes centrados em analisadores sintáticos.