Quatro palavras para esta página.
O painel que roda os testes a cada mudança e fica verde quando nenhum falhou. É o sinal que libera a mudança para produção.
Um teste que ficaria vermelho se o código estivesse errado do jeito que importa. Só esse tipo transforma o verde em informação.
Uma cópia do código com um erro de propósito, como trocar um sinal. Se os testes não percebem, também não perceberiam o erro de verdade.
O que decide se o trabalho passou. Quando quem é avaliado pode mexer na régua, o resultado mede a régua, não o trabalho.
Um detector sem bateria também fica em silêncio.
Um detector de fumaça que não apita pode significar duas coisas: não há fogo, ou o detector não funciona. De fora, o silêncio é o mesmo. A única forma de saber qual das duas é testar o detector: pôr fumaça perto e ver se ele apita.
Com testes de software é igual. Um teste que falha diz muito: há algo errado, e ele aponta onde. Um teste que passa diz quase nada, a menos que ele tivesse falhado se o código estivesse errado. O verde é a soma de vários silêncios, e cada silêncio vale o que valia o teste.
O erro comum não é ter poucos testes. É ler o silêncio como certificado: o relatório diz "passou em todos os testes", e quem lê entende "está certo". São frases diferentes, e o espaço entre elas é onde os defeitos moram.
Aprovado pelos testes, errado de fato.
O SWE-bench é o placar mais citado para comparar agentes de IA que programam. Cada tarefa é um problema real, registrado num projeto público. O agente escreve a correção, e ela conta como resolvida se passar nos testes escolhidos para aquela tarefa. O placar inteiro é feito de verdes.
Em 2025, dois grupos foram conferir esses verdes. Um deles rodou a suíte completa dos próprios desenvolvedores nas correções aprovadas: 7,8% passavam nos testes da tarefa e falhavam na suíte completa. E 29,6% das correções aceitas se comportavam diferente da correção feita pelas pessoas do projeto. Somado, o índice de problemas resolvidos estava inflado em 6,2 pontos percentuais.
O outro grupo acrescentou testes onde faltavam e achou 176 correções erradas aprovadas numa versão do placar e 169 noutra. Com a régua consertada, a posição de 40,9% dos concorrentes mudou numa das tabelas. Nenhuma dessas correções tinha mentido: os testes é que não conseguiam falhar para elas.
Há um problema anterior, registrado no próprio repositório do SWE-bench: em algumas montagens, o agente consegue alterar os arquivos de teste que depois vão julgá-lo. Quando o avaliado pode mexer na régua, o verde mede a régua.
O teste rigoroso cobra na hora. O frouxo cobra de outra pessoa, depois.
Esta parte é leitura nossa, não medição. Um teste rigoroso demais falha em código que funcionava: trava a entrega, alguém perde uma tarde descobrindo por quê, e o teste leva a culpa. Um teste frouxo deixa passar um defeito: a entrega sai no prazo, e a conta chega semanas depois, em produção, para outra equipe ou para o cliente.
O custo do rigor é imediato e tem dono; o custo da frouxidão é atrasado e difuso. Sem ninguém decidir nada, a pressão do dia a dia empurra as suítes para o lado frouxo: o teste que incomoda é afrouxado ou apagado, o que nunca falha fica. Com o tempo, o verde fica mais frequente e vale menos.
O conserto é tornar a frouxidão cara para quem a escolhe: medir, de tempos em tempos, se os testes ainda conseguem falhar. É o que o espécime faz.
Pôr fumaça perto do detector.
A forma de testar os testes existe há décadas: plantar defeitos de propósito. Faz-se uma cópia do código com um único erro pequeno, como trocar um sinal ou mudar um número, e roda-se a suíte. Se ela fica vermelha, o defeito foi percebido. Se continua verde, a suíte não enxerga aquele tipo de erro. A fração de defeitos percebidos é a nota da suíte, não do código.
No espécime, os três testes que vêm marcados são o que uma suíte comum costuma ter: roda sem erro, um caso típico abaixo do limite, um acima. Fica verde e percebe cinco dos oito defeitos plantados. O defeito real passa: o código cobra frete de um pedido de exatamente R$ 199, e nenhum desses testes olha para o limite.
Tentamos levar isso para mudanças reais, e esbarramos no alcance. Numa amostra parcial, de um projeto só, as ferramentas prontas de plantar defeitos quase nunca conseguiam plantar algum dentro do trecho que a mudança alterou. A ideia é boa; as ferramentas de prateleira não chegam onde a mudança típica mexe.
O teste escrito a partir do código protege o defeito.
Hoje é comum pedir a um modelo de IA que escreva os testes de uma mudança. Medimos isso em agosto, em dois projetos públicos em Go. Separamos 19 mudanças que sabíamos conter um defeito, porque ele foi corrigido depois, e 10 mudanças limpas do mesmo tamanho. Para cada uma, um agente de IA, sem saber de que grupo era e sem ver a correção, escreveu testes a partir do código e da descrição da mudança.
Os testes gerados não pegaram nenhum dos 19 defeitos. O motivo é o mesmo do retrato do código atual no espécime: quem escreve o teste olhando o código registra o que o código faz, inclusive o erro. O teste nasce concordando com o defeito.
Dois detalhes importam. Nos dois únicos casos em que a descrição da mudança dizia uma coisa e o código fazia outra, visivelmente, o teste falhou e apontou um defeito real. E nas 10 mudanças limpas o método quase não inventou alarme: disparou uma vez, e com razão. Serve para absolver, não para acusar. É a mesma divisão que encontramos quando uma IA confere outra, numa entrada anterior deste caderno.
| Grupo | Mudanças | O teste gerado ficou vermelho | Leitura |
|---|---|---|---|
| Com defeito conhecido | 19 | 0 | Não pegou nenhum. O teste herdou o que o código faz. |
| Limpas, do mesmo tamanho | 10 | 1 | Quase não inventa alarme, e o único era verdadeiro. |
| Entre as 29, descrição e código divergiam visivelmente | 2 | 2 | O único lugar onde o teste gerado morde. |
Medição nossa, agosto de 2026, com critério de derrota registrado antes: a aposta de que o teste gerado recuperaria defeitos morreu. A amostra é pequena, e parte dos testes não compilou na versão corrigida, o que é limite do nosso jeito de conferir, não do método em uso real.
Quatro regras para o verde voltar a dizer alguma coisa.
Pergunte se o teste consegue falhar
De tempos em tempos, plante defeitos e veja quais passam. A nota da suíte vale mais que a contagem de testes ou a porcentagem de linhas cobertas.
Escreva o teste pela regra, não pelo código
O teste que nasce da especificação discorda do código quando o código está errado. O que nasce do código concorda com ele, inclusive no erro.
Quem é avaliado não mexe na régua
Nem pessoa nem agente de IA altera os testes que vão julgar a própria mudança sem que alguém veja. Arquivo de teste mudado junto com o código é um alerta por si só.
Chame o verde pelo nome
No relatório, "sem alarme nos testes X, Y e Z", não "aprovado". A diferença de palavras é a diferença entre o que foi medido e o que se gostaria que fosse verdade.
Onde isso pode estar errado.
Os números do placar são de outros
Os percentuais do SWE-bench vêm de dois estudos de 2025, cada um com o próprio método. Conferimos os resumos publicados, não refizemos as contas.
A nossa amostra é pequena
29 mudanças, dois projetos, uma linguagem. E o que chamamos de "defeito conhecido" depende de ligar cada correção à mudança que a causou, o que às vezes erra.
Plantar defeitos tem custo e ponto cego
Rodar a suíte para cada defeito plantado é caro, e alguns defeitos plantados não mudam o comportamento, então nenhum teste poderia percebê-los. A nota da suíte é uma estimativa, não um veredito.
O espécime é de brinquedo
Uma função de três linhas deixa o mecanismo visível. Em código real, os defeitos que escapam tendem a morar onde nem existe um jeito simples de testar.
← Caderno de pesquisa · O barato absolve · stickybit.com.br
- Wang, Pradel e Liu, "Are 'Solved Issues' in SWE-bench Really Solved Correctly? An Empirical Study" (arXiv, 2025): 7,8%, 29,6% e a inflação de 6,2 pontos.
- Yu e coautores, "UTBoost: Rigorous Evaluation of Coding Agents on SWE-Bench" (ACL 2025): 176 e 169 correções erradas aprovadas; 40,9% das posições alteradas no SWE-bench Lite.
- O problema de o agente poder alterar os testes que o julgam está registrado nos issues do repositório do SWE-bench.
- Medições nossas, agosto de 2026: testes gerados por agente de IA para 29 mudanças de dois projetos públicos em Go, e a tentativa de plantar defeitos em mudanças reais (amostra parcial, encerrada antes do fim).
- O espécime roda no seu navegador: uma função, seis testes e oito cópias com um defeito plantado cada.