Resumo Técnico: PBT-Bench

Definição do Problema

Os benchmarks existentes de geração de código (por exemplo, SWE-Bench, SWT-Bench) avaliam principalmente a capacidade de um agente de produzir um patch para um bug conhecido ou gerar um teste unitário com base em um relatório de bug específico. Esses benchmarks falham em isolar a habilidade cognitiva distinta necessária para Testes Baseados em Propriedades (PBT): a capacidade de derivar um invariante semântico a partir de documentação abstrata e construir uma estratégia precisa de geração de entrada (uma "estratégia de busca") capaz de disparar uma violação por meio de amostragem aleatória.

Os benchmarks atuais frequentemente dependem de relatórios de bugs minerados onde a correção inclui testes unitários concretos, ou exigem que agentes escrevam casos de teste finitos e concretos. Isso confunde a capacidade geral de codificação com a habilidade específica de PBT de traduzir especificações abstratas em invariantes universais e distribuições programáticas de entrada. Além disso, muitos bugs do mundo real (por exemplo, renderização de interface de usuário, dependências de estado de banco de dados) não são testáveis por PBT porque carecem de gatilhos determinísticos ou invariantes documentados. Há uma necessidade de um benchmark curado que avalie estritamente o fluxo de trabalho de PBT: leitura de documentação, identificação de invariantes e especificação de uma estratégia @given do Hypothesis que concentre a massa de probabilidade na região de gatilho do bug.

Metodologia

O Benchmark PBT-Bench

Os autores introduzem o PBT-Bench, um benchmark consistindo em 100 problemas de testes baseados em propriedades curados através de 40 bibliotecas Python reais (abrangendo serialização, estruturas de dados, data-hora, numéricos, sistemas de tipos, máquinas de estado e análise sintática).

• Injeção de Bugs: O benchmark contém 365 bugs semânticos injetados. Estes não são minerados de pull requests, mas são cuidadosamente projetados para satisfazer quatro critérios estritos de testabilidade por PBT:
  1. Semântico: O bug viola um invariante ou contrato documentado (por exemplo, identidade de ida-e-volta, comutatividade, monotonicidade).
  2. Expressividade: O invariante pode ser codificado como uma propriedade @given do Hypothesis sem efeitos externos (arquivos, sockets, relógios).
  3. Furtividade: O bug não é facilmente detectável por inspeção manual curta e tipicamente reside em caminhos de código pouco testados.
  4. Gatilho Determinístico: Existe uma região de entrada bem definida onde o bug se manifesta com probabilidade um (ou uma sequência de estado específica), e a estratégia de verdade concentrada foca a massa ali.
• Taxonomia de Dificuldade: Os problemas são estratificados em três níveis:
  • L1 (Restrição Única): Bugs de limite ou restrições de entrada únicas.
  • L2 (Múltiplas Restrições): Requer satisfazer múltiplas condições simultâneas (intervalos de valores, restrições estruturais, ordenação).
  • L3 (Cross-function/Protocolo): Requer testes sobre sequências de chamadas de API ou testes metamórficos abrangendo múltiplas operações.
• Ferramenta de Avaliação: O benchmark utiliza uma ferramenta containerizada Falhar-em-Bug, Passar-em-Correção (F→P).
  • Container do Agente: Contém a biblioteca com bug, documentação (o único oráculo) e uma suíte de testes existente que passa.
  • Container de Avaliação: Após o agente escrever um arquivo de teste, a ferramenta avalia independentemente cada bug injetado. Ela restaura a versão com bug, executa o teste, reverte o patch específico do bug e reexecuta. Um bug é "encontrado" se pelo menos uma função de teste falhar na versão com bug e passar na versão corrigida.
  • Pontuação: Os bugs são pontuados individualmente, mesmo que múltiplos bugs existam em um único arquivo de problema, impedindo que uma pontuação global mascare o sucesso parcial.

Configuração Experimental

Os autores avaliaram oito Modelos de Linguagem Grandes (LLMs) contemporâneos (incluindo Claude Sonnet 4.6, DeepSeek V3.2, Gemini 3 Flash, GLM 5.1, Grok 4.1 Fast, Qwen 3.6 Plus, Qwen 3.5-30B-A3B e Step 3.5 Flash) usando a estrutura de agente OpenHands.

Cada modelo foi testado sob dois regimes de prompt, repetidos para três execuções independentes:

1. Linha de Base (Aberto): Instruções para entender a biblioteca, encontrar comportamento não coberto e escrever um teste falho. Nenhuma menção a PBT, Hypothesis ou @given.
2. PBT (Estruturado): Instruções explícitas para usar o framework Hypothesis, exigindo decoradores @given e uma taxonomia específica de propriedades (Roundtrip, Modelo-oráculo, Invariante, Limite).

Contribuições Principais

1. PBT-Bench: O primeiro benchmark que avalia especificamente a capacidade de agentes de codificação de usar PBT para detecção de bugs em bibliotecas de programas, apresentando 100 problemas e 365 bugs verificados com estratégias de verdade.
2. Ferramenta Automatizada F→P: Um sistema de avaliação containerizado que pontua por bug em vez de por problema, permitindo uma avaliação granular de agentes escrevendo múltiplos testes em um único arquivo.
3. Avaliação em Grande Escala: Uma avaliação abrangente de 8 modelos através de 2 regimes de prompt, gerando 4.800 trajetórias de agentes.
4. Descobertas Empíricas:
   • Efeito de Estruturação: A estruturação de PBT beneficia significativamente modelos de capacidade média (por exemplo, +24,5% para Qwen 3.6 Plus), mas produz ganhos menores ou até negativos para os modelos mais fortes (por exemplo, -8,0% para Grok 4.1 Fast), sugerindo que a estruturação substitui capacidades ausentes em modelos mais fracos em vez de complementar habilidades existentes em modelos mais fortes.
   • Especificidade do Modelo: Nenhum modelo único domina os bugs mais difíceis (L2/L3); diferentes arquiteturas falham em problemas diferentes.
   • Potencial de Ensemble: Uma união de todos os pares modelo-modos alcança 99,5% de recuperação de bugs, indicando um "espaço livre" significativo onde modelos diversos se complementam. Apenas dois dos 365 bugs nunca foram encontrados de forma confiável por qualquer configuração.

Resultados

• Recuperação de Bugs: Sob o prompt guiado por PBT, a recuperação de bugs variou de 42,1% (Grok 4.1 Fast) a 83,4% (Claude Sonnet 4.6). Sob a linha de base aberta, a recuperação variou de 31,4% a 76,7%.
• Impacto do Prompt: A lacuna entre o desempenho de PBT e da Linha de Base foi maior para modelos com linhas de base mais fracas. Para o modelo mais forte (Sonnet 4.6), o ganho foi de +6,7 pontos percentuais. Para modelos mais fracos como Qwen 3.5-30B-A3B, o ganho foi de +22,9 pontos percentuais.
• Modos de Falha:
  • As falhas da Linha de Base foram dominadas por Asserção Incorreta (59%) e Testes Excessivamente Concretos (32%), onde os agentes miravam no invariante errado ou usavam entradas codificadas.
  • As falhas de PBT deslocaram-se para patologias de busca, principalmente Mau Uso de Assume (31%), onde os agentes usaram hypothesis.assume() para filtrar as próprias entradas que disparam o bug, e Intervalo de Estratégia Errado (31%), onde a distribuição de entrada era muito ampla ou estreita.
• Desempenho de Ensemble: A "união gananciosa" de todas as 16 configurações de modelo-modo alcançou 99,5% de recuperação confiável. A maioria dos ganhos marginais veio da complementaridade de modos dentro do mesmo modelo (por exemplo, Sonnet PBT + Sonnet Linha de Base), sugerindo que estratégias de prompt elicitar comportamentos de teste diferentes mesmo dentro da mesma arquitetura.

Significado e Alegações

O artigo afirma que o PBT-Bench isola uma lacuna de capacidade crítica nos agentes de codificação atuais: a transição de invariantes documentados para estratégias precisas de geração de entrada aleatória. Os resultados sugerem que, embora a estruturação de PBT possa efetivamente impulsionar o desempenho de modelos de nível médio ao fornecer a estrutura necessária, ela não melhora universalmente o desempenho e pode até restringir as estratégias de busca de modelos mais fortes.

Os autores enfatizam que o PBT permanece uma lacuna de capacidade persistente; mesmo o modelo atual mais forte (Sonnet 4.6) falha em encontrar de forma confiável 16,6% dos bugs, e o ensemble de todos os modelos ainda falha em encontrar de forma confiável dois bugs L3 específicos (bug_3 do BIDC-004 e bug_1 do TMLK-005) que exigem sequências de estado complexas.

O artigo conclui que o PBT-Bench complementa os benchmarks minerados existentes (como TESTEXPLORA e SWT-Bench) medindo a profundidade na distribuição específica de bugs para os quais o PBT é a ferramenta pretendida. Os autores lançam o benchmark, a ferramenta e o corpus de avaliação para apoiar trabalhos subsequentes sobre raciocínio semântico fundamentado em documentação. Eles reconhecem limitações, incluindo o trade-off entre fidelidade populacional e testabilidade por PBT em bugs curados, a restrição ao Python com documentação em inglês e o impacto potencial do orçamento de busca max_examples=200 em bugs de gatilho estreito.