Resumo Técnico: Geração de Testes de Reprodução para Problemas SWE em Java

Declaração do Problema

O artigo aborda a lacuna crítica na engenharia de software (SWE) automatizada para Java: a geração de testes de reprodução. Um teste de reprodução é definido como um teste que falha na base de código atual (confirmando a presença de um problema) e passa após o problema ser corrigido (confirmando sua ausência). Embora avanços recentes tenham produzido benchmarks e soluções para Python, o Java permanece subatendido, apesar de sua dominância no software empresarial. Ferramentas existentes focadas em Java carecem de capacidades de localização de falhas, dependem de variantes simplificadas de problemas ou sofrem de contaminação de conjuntos de dados e sobreajuste. Além disso, bugs de Java empresarial frequentemente diferem em distribuição e complexidade dos bugs de Python de código aberto, necessitando de abordagens especializadas que levem em conta o sistema de tipos estático e a natureza orientada a objetos do Java.

Metodologia

Os autores propõem e-Otter++ para Java, uma adaptação de um gerador de testes de reprodução de última geração para Python. A metodologia é um pipeline de múltiplos estágios projetado para lidar com a complexidade ao nível de repositório sem exigir acesso ao código de correção ($c_{new}$) durante a geração.

1. Arquitetura do Pipeline

O fluxo de trabalho consiste em quatro componentes principais:

• Localizador: Identifica "funções focais" (prováveis de serem modificadas) e testes de regressão relacionados. Diferentemente da versão Python, que separava essas tarefas, a versão Java as funde em um único passo para lidar com a maior frequência de novos arquivos de teste em projetos Java. Utiliza um processo de três etapas com LLM: seleção de arquivos relevantes por nome, seleção de funções por nome e, finalmente, filtragem baseada nos corpos das funções.
• Contextualizador: Constrói a estrutura necessária para um novo arquivo de teste, o que é comum em Java. Determina o nome do pacote correto, as importações e o caminho do arquivo consultando o repositório e selecionando entre opções existentes para minimizar alucinações.
• Gerador de Teste Inicial: Gera um candidato inicial de teste ($t_{ot}$) como uma nova classe em um novo arquivo, instruído com a descrição do problema e o contexto localizado.
• Refinador: Melhora iterativamente o teste usando feedback de execução. Executa o teste no código antigo ($c_{old}$), analisa os logs via um crítico baseado em LLM e reescreve o teste se falhar pelo motivo errado. Este loop é executado até 10 vezes, acumulando alterações para prevenir erros repetitivos.

2. Escalonamento de Inferência via Prompting Heterogêneo

Para aumentar a diversidade de candidatos a teste, o sistema emprega prompting heterogêneo em vez de amostragem baseada em temperatura. A descrição do problema é reescrita em seis variantes distintas (morfos):

• Padrão: Reescrita em um formato estruturado.
• Simples: Remoção de jargão e simplificação do texto.
• dropCode: Remoção de trechos de código potencialmente enganosos.
• initTest: Incorporação de um teste inicial gerado no prompt.
• initPatch: Incorporação de um patch de código sugerido no prompt.
• Padrão: Uso da descrição original do problema.

Um Seletor de Testes avalia então os seis candidatos resultantes (juntamente com seus logs de execução) e seleciona o único melhor teste para submissão.

Contribuições Principais

1. TDD-Bench-Java: O primeiro benchmark ao nível de repositório especificamente para geração de testes de reprodução em Java. Composto por 250 instâncias provenientes de repositórios de código aberto populares (por exemplo, Trino, Jackson, RocketMQ), filtrados para garantir o comportamento "falha-para-sucesso". O conjunto de dados inclui diversas ferramentas de construção (Maven, Gradle) e estruturas de projeto.
2. e-Otter++ para Java: Uma solução robusta adaptada de fluxos de trabalho Python, alcançando alto desempenho no novo benchmark. É a primeira solução completa para geração de testes de reprodução em Java ao nível de repositório que inclui localização de falhas.
3. Avaliação Industrial Proprietária: O artigo avalia o sistema em um conjunto de dados proprietário livre de contaminação de 150 problemas de um projeto interno Java da IBM. Isso fornece insights sobre os desafios de aplicar esses modelos a código empresarial real, que frequentemente difere significativamente dos dados de código aberto.

Resultados

Benchmark Público (TDD-Bench-Java)

Utilizando os modelos Claude-Sonnet-4.5 e GPT-5.2, o e-Otter++ alcançou:

• 43,6% de taxa de falha-para-sucesso com Claude-Sonnet-4.5.
• 46,4% de taxa de falha-para-sucesso com GPT-5.2.

Principais Descobertas:

• Impacto do Refinamento: A etapa de refinamento (e-Otter) melhorou significativamente o desempenho sobre o gerador inicial (Otter), com melhorias relativas variando de 26,2% a 64,3%, dependendo do modelo e do morfo.
• Prompting Heterogêneo: O uso de seis morfos aumentou a taxa de falha-para-sucesso em N=6 (pelo menos um candidato tem sucesso) em mais de 32% em comparação com abordagens de variante única.
• Significância Estatística: Os testes de McNemar confirmaram que as melhorias de Otter para e-Otter foram estatisticamente significativas ($p < 0,01$).

Resultados do Conjunto de Dados Proprietário

O desempenho no conjunto de dados interno da IBM foi menor, destacando a dificuldade do código empresarial:

• Desempenho Padrão: Com descrições de problema padrão, a taxa de falha-para-sucesso foi de apenas 4% (6/150).
• Com Dicas: Quando o sistema recebeu "dicas" (novos nomes de classes e assinaturas de funções derivadas do patch de código), a taxa melhorou para 20% (30/150).
• Características dos Dados: Problemas proprietários eram mais curtos, careciam de trechos de código e envolviam patches de código significativamente maiores (média de 362 linhas versus 55 linhas nos dados públicos). Além disso, 84% dos problemas proprietários eram solicitações de recursos em vez de correções de bugs, frequentemente introduzindo novos arquivos que os modelos têm dificuldade em antecipar.

Significado e Alegações

O artigo alega fazer uma contribuição significativa para o campo ao:

1. Preencher a Lacuna de Linguagem: Fornecer o primeiro benchmark e solução dedicados para Java, uma linguagem crítica para software empresarial, mas anteriormente negligenciada na pesquisa de geração de testes de reprodução.
2. Relevância Industrial: Ir além dos benchmarks de código aberto para avaliar o desempenho em dados proprietários, revelando que, embora os modelos se saiam bem em dados públicos curados, enfrentam desafios substanciais com o "ruído" e a complexidade de problemas empresariais reais (por exemplo, descrições curtas, geração de novos arquivos).
3. Rigor Metodológico: Demonstrar que o escalonamento de inferência via prompting heterogêneo e refinamento orientado à execução são estratégias eficazes para Java, mesmo quando o sistema de tipos estático introduz erros em tempo de compilação que diferem dos erros em tempo de execução do Python.

Os autores concluem que, embora as abordagens atuais baseadas em LLM mostrem promessa, trazer diagnóstico e validação confiáveis para o desenvolvimento de software Java requer inovação adicional, particularmente no tratamento de problemas mal especificados e na geração de contexto preciso para novas estruturas de código.