Resumo Técnico: EvoOtter

Definição do Problema

A geração de Testes de Reprodução de Bugs (BRTs) é uma etapa crítica na engenharia de software, servindo para confirmar a presença de um bug antes que uma correção seja aplicada. Diferente da geração de testes tradicional, que visa testes que passam, um BRT deve ser "falhar-para-passar" (F2P): ele deve falhar no código bugado atual ($c_{old}$), mas passar no futuro código resolvido ($c_{new}$).

O principal desafio na geração de BRTs é a falta de feedback confiável. Como o código resolvido ($c_{new}$) não está disponível durante a geração, é difícil determinar se um candidato falha pelo motivo correto ou para selecionar o melhor candidato entre muitos. Abordagens anteriores basearam-se em "escalonamento de inferência" — gerando muitos candidatos e usando Modelos de Linguagem de Grande Escala (LLMs) ou feedback de execução para selecioná-los e melhorá-los. No entanto, esses métodos são frequentemente caros devido ao alto número de chamadas de LLM e sofrem de feedback pouco confiável ou overfitting de teste.

Metodologia: EvoOtter

O EvoOtter aborda esses desafios combinando programação evolutiva com LLMs, especificamente adaptada para reduzir custos e refinar os sinais de feedback. O fluxo de trabalho opera sobre uma população de testes candidatos e uma população de mutantes de código.

1. Ciclo Evolutivo Central

O sistema mantém duas populações:

• Predadores: Candidatos a BRTs.
• Presas: Variantes bugadas do código (mutantes).

O ciclo evolutivo procede da seguinte forma:

1. Inicialização: Um gerador base cria $n$ testes iniciais diversos (tipicamente 8) usando prompting heterogêneo para variar descrições de problemas e contexto.
2. Geração de Mutantes: Um gerador baseado em regras cria $m$ mutantes de código aplicando operadores de mutação específicos (ex: trocas aritméticas, substituições de constantes, forçar falhas) a funções focais localizadas que suspeitam conter o bug. Nenhum LLM é usado para esta etapa.
3. Avaliação de Fitness: Cada teste é executado contra a população atual de mutantes. A pontuação de fitness é definida como o número de mutantes "mortos" pelo teste.
   • Novidade na Definição de Matar: Como o código original já é bugado, um teste que mata um mutante não é definido simplesmente por uma falha de teste. Em vez disso, o sistema analisa os logs de execução. Um mutante é considerado "morto" se o teste falha no mutante por um motivo diferente do que falhou no código original (indicado por uma mudança na saída do log).
4. Seleção (Successive Halving/Redução Sucessiva): Os testes são ordenados por fitness, e a metade inferior é descartada. Para manter um sinal de feedback forte enquanto mantém os custos de execução constantes, o sistema dobra o número de mutantes na próxima geração (amostrando de um pool pré-gerado) enquanto reduz pela metade a população de testes. Este processo se repete até que reste um único teste.
5. Crossover (Reparo em Lote): Os testes sobreviventes são usados como pais. Uma única chamada de LLM é usada para gerar toda a próxima geração de descendentes. O LLM é instruído a intercalar, adicionar ou remover instruções entre os testes pais e seus logs de execução para melhorá-los. Este "crossover em lote" evita o alto custo de chamadas individuais de LLM por teste.

2. Mecanismos de Controle de Custo

• Successive Halving: Reduz a população de testes pela metade a cada geração enquanto dobra a população de mutantes, mantendo o número total de execuções de teste por iteração constante ($2m$).
• Batched Crossover: Gera todos os descendentes de uma geração em uma única chamada de LLM em vez de uma chamada por candidato.
• Mutantes Baseados em Regras: Utiliza regras de reescrita de código determinísticas para mutantes em vez de LLMs, reservando os LLMs estritamente para a geração e evolução de testes.
• Opção de Prompt Único: Embora o padrão use prompting heterogêneo para diversidade inicial, o sistema suporta um modo de "prompt único" onde uma única chamada de LLM gera todos os candidatos iniciais. Isso reduz significamente os custos e permite o uso de modelos de raciocínio mais poderosos (mas caros) como o Claude-Opus-4.7.

Principais Contribuições

1. Fluxo de Trabalho EvoOtter: O primeiro fluxo de trabalho de geração de BRT baseado em programação evolutiva, integrando testes de mutação e redução sucessiva.
2. Pontuação de Fitness Baseada em Mutação: Uma métrica de fitness inovadora que conta o número de mutantes de código baseados em regras mortos por um teste, utilizando diferenças de log para lidar com o cenário de "código original bugado".
3. Batched Crossover: Uma técnica que aproveita as capacidades dos LLMs modernos para evoluir uma geração inteira de testes em uma única chamada, equilibrando desempenho com custo.

Resultados Experimentais

Os autores avaliaram o EvoOtter em três benchmarks: TDD-Bench-Verified, SWE-Rebench e SWT-Bench-Verified.

• Desempenho: Usando Claude-Sonnet-4.5 com prompting heterogêneo, o EvoOtter alcançou uma taxa de F2P de 65,9% no TDD-Bench-Verified e 51,9% no SWE-Rebench, superando baselines anteriores que dependem apenas de seleção ou reparo (ex: e-Otter).
• Estado da Arte: Utilizando single prompting com o modelo de raciocínio mais forte, Claude-Opus-4.7, o EvoOtter alcançou 75,3% no TDD-Bench-Verified e 66,3% no SWE-Rebench. No leaderboard do SWT-Bench-Verified, atingiu 77,8%.
• Eficiência de Custo: O EvoOtter alcança estes resultados por uma fração do custo de abordagens de escalonamento de inferência anteriores. O custo médio por instância é de aproximadamente $0,17 (excluindo a geração inicial) para o fluxo de trabalho padrão, e $0,88 para a variante de alto desempenho de prompt único, comparado a custos significativamente maiores para métodos que exigem loops de reparo individuais.
• Análise de Componentes:
  • Seleção: A seleção baseada em mutação superou a seleção baseada em LLM e a seleção aleatória nas fases evolutivas tardias, embora os LLMs tenham tido bom desempenho na fase inicial.
  • Crossover: Remover o crossover causou uma queda de desempenho de mais de 10%, destacando seu papel crítico.
  • Diversidade: O single prompting reduziu ligeiramente a diversidade, mas não impediu que os operadores evolutivos selecionassem e melhorassem os testes de forma eficaz.

Significância e Alegações

O artigo afirma que o EvoOtter demonstra como combinar de forma eficiente e eficaz a programação evolutiva com LLMs para tarefas de engenharia de software. Sua principal significância reside em:

• Robustez: Fornecer sinais de feedback mais confiáveis através de testes de mutação em vez de depender apenas de julgamentos possivelmente ruidosos de LLMs ou da execução no código bugado isoladamente.
• Eficiência: Reduzir drasticamente o custo da geração de BRT ao minimizar as chamadas de LLM através de operações em lote e redução sucessiva, tornando a abordagem escalável.
• Praticidade: Alcançar resultados de estado da arte em benchmarks verificados mantendo um baixo custo de inferência, sugerindo que estratégias evolutivas podem ser uma alternativa viável ao puro escalonamento de inferência para tarefas complexas de engenharia de software.

Os autores observam que suas descobertas estão atualmente limitadas a repositórios Python e que as escolhas de design (como o single-prompting) são adaptadas às capacidades dos modelos de fronteira recentes.