TDD com agente: o teste vale, o ritual não

Duas medições recentes parecem brigar.

Uma diz que testes escritos por LLM detectam falha em 69% dos casos, contra 17,2% dos testes humanos de propósito geral. Outra diz que mandar o agente seguir TDD não produziu diferença discernível contra não mandar, e custou de três a oito vezes e meia mais tokens.

As duas estão certas, e a reconciliação é o assunto deste post: elas medem coisas diferentes. Uma mede o teste. A outra mede a cerimônia em volta do teste.

Este texto separa as duas, mostra por que cobertura é a métrica errada, e termina no que usar no lugar do ritual. É a camada de verificação da engenharia de harness, medida em vez de assumida. É a continuação de por que o agente não revisa o próprio trabalho: lá ficou estabelecido que ele precisa de sinal externo. Aqui se vê que o teste é esse sinal, e funciona — mas o red-green-refactor não é o que o faz funcionar.

O resultado é mais forte do que a discussão pública sugere.

Em LLM vs. Human Unit Tests: Fault Detection on Real Python Bugs, de Phouvadeth Vathana, Prapti Bhatt, Rishi Patel e Nasir U. Eisty, testes gerados por LLM detectaram falhas em 69% dos casos, contra 17,2% dos testes humanos de propósito geral. A diferença é estatisticamente sólida: Fisher exato com p abaixo de 0,001 e tamanho de efeito de 1,10 na medida de Cohen (arXiv 2606.08588, 7 de junho de 2026).

O método importa para saber o alcance. Foram 29 bugs históricos do BugsInPy, mais benchmarks em nível de função nas bibliotecas python-slugify e packaging. O modelo foi o Gemini 2.5 Flash, com contexto aumentado por recuperação — e os autores registram que esse contexto recuperado foi crítico para o resultado.

É um estudo forte e estreito ao mesmo tempo: um modelo, uma linguagem, 29 bugs. Não sustenta "IA escreve testes melhores que humanos" como lei geral. Sustenta que, nessas condições, o artefato produzido pela máquina encontrou quatro vezes mais defeitos.

Quanto disso já está acontecendo

Não é cenário de laboratório. Um estudo apresentado na 23ª International Conference on Mining Software Repositories analisou 2.232 commits com mudança de teste, do conjunto AIDev, e encontrou que 16,4% de todos os commits que adicionam teste foram escritos por IA (arXiv 2603.13724, Yoshimoto, Fujita, Horikawa, Feitosa, Kashiwa e Iida, março de 2026).

O mesmo trabalho descreve o perfil estrutural desses testes: código mais longo, densidade de asserção maior e complexidade ciclomática menor que a dos humanos, por usarem lógica linear. A cobertura alcançada é comparável.

Guarde a densidade de asserção. Ela parece qualidade e volta neste post como risco: muitas asserções não garantem que alguma delas verifique a coisa certa.

O detalhe que reorganiza a discussão está nos números de cobertura do mesmo estudo.

Os testes gerados por LLM tiveram cobertura menor que a dos humanos: 84,8% contra 88,5% em linha, e 75,2% contra 82,1% em ramo. Menos cobertura, quatro vezes mais detecção.

Os próprios autores concluem que métricas de cobertura sozinhas não medem qualidade de teste. Isso tem consequência direta para quem usa cobertura como portão de integração contínua: o número que trava o merge é o que menos informa sobre encontrar defeito.

Cobertura mede se a linha foi executada. Não mede se alguma coisa foi verificada quando ela executou. Um teste que chama a função e não afirma nada cobre tudo e não encontra nada.

Agora a outra ponta, e ela é desconfortável para quem defende TDD por princípio.

Em TDD inside the agent loop, publicado em 10 de agosto de 2026, Birgitta Böckeler investigou se instruir um agente a seguir TDD dentro do próprio loop melhora o código e os testes resultantes. A conclusão é direta: "não houve diferença claramente discernível entre o fluxo com TDD e o fluxo sem TDD" (martinfowler.com).

Os detalhes pioram o quadro para o ritual. Em cinco lotes de tarefas, as soluções sem TDD ficaram em primeiro e segundo lugar nas tarefas pequenas e médias; as com TDD, em terceiro e quarto. Só quando o prompt enfatizava explicitamente revisão de desenho é que uma solução com TDD ficou em primeiro.

E o custo: o caminho com TDD consumiu de 3 a 8,5 vezes mais tokens. É uma diferença que muda orçamento, e o assunto de onde o dinheiro vaza em produção trata do que isso significa em escala.

A tabela é a tese do post. O artefato é bom. A cerimônia não se pagou.

Onde o ritual ainda faz sentido

Antes de jogar fora, três ressalvas honestas. Duas vêm do próprio estudo.

Quando o prompt pede revisão de desenho. Foi a única condição em que uma solução com TDD ficou em primeiro lugar. Isso sugere que o ganho não veio da ordem dos passos, e sim da atenção explícita à arquitetura. Se é a atenção que produz o efeito, dá para pedi-la direto, sem o ciclo inteiro.

Quando a tarefa é grande. O resultado de ranking citado vale para tarefas pequenas e médias. Nada no material sustenta a conclusão para refatorações longas ou features que atravessam muitos arquivos, e o custo de errar ali é outro.

Quando quem escreve é humano. Nada disso mede TDD feito por pessoa. O método nasceu para dar ritmo e feedback curto a quem programa, e a medição aqui é sobre instruir um agente a imitá-lo dentro do próprio loop. São perguntas diferentes, e confundir as duas seria o mesmo erro que este post cobra dos outros.

O que a evidência autoriza dizer é estreito e útil: mandar o agente seguir TDD, em tarefa pequena ou média, não mostrou ganho e custou caro. Não autoriza dizer que TDD morreu.

Böckeler nomeia cinco comportamentos que explicam por que o ritual não pega.

Repare no padrão: quatro dos cinco são o agente não fazendo a disciplina que foi mandado fazer. O TDD não falhou como método; ele não foi executado, mesmo instruído.

O quinto, o teste tautológico, é diferente e mais grave. Ele merece seção própria.

Um teste tautológico afirma o que o código faz, não o que ele deveria fazer. Quando alguém escreve o teste olhando a implementação, é isso que sai: uma cópia do comportamento atual, com aparência de verificação.

Com agente, o problema se agrava por um motivo estrutural: quando o mesmo modelo escreve o código e o teste, os dois compartilham o mesmo ponto cego. Se ele entendeu a regra de negócio errado, vai implementar errado e verificar errado — com asserção densa, sintaxe impecável e cobertura alta.

Aqui a densidade de asserção que o estudo do MSR mediu deixa de ser sinal de qualidade. Vinte asserções sobre o comportamento errado continuam sendo vinte asserções erradas, e o número alto dá a impressão contrária. Densidade mede quanto o teste afirma, não se ele afirma a coisa certa — o mesmo defeito da cobertura, num andar acima.

É o mesmo limite descrito em por que o agente não revisa o próprio trabalho, aplicado ao teste. O agente não encontra o próprio erro porque o erro nasceu do entendimento dele. Escrever o teste antes não resolve, porque o entendimento é o mesmo nos dois momentos.

A defesa não é de processo, é de fonte: o teste precisa vir de algo que o modelo não inventou. Especificação escrita antes, exemplo real de entrada e saída, bug reproduzido com dado de produção, contrato de API. Foi exatamente isso que o estudo de detecção observou ao chamar o contexto recuperado de crítico — os testes eram bons porque tinham de onde tirar a verdade.

Existe uma evidência de segunda ordem que vale mais que argumento: alguém precisou construir um guardrail para isso.

O tdd-guard é uma ferramenta de código aberto cuja função declarada é impor TDD ao Claude Code bloqueando ações quando o agente tenta pular testes ou implementar além do necessário. Ou seja: alguém automatizou a contenção de dois dos cinco modos de falha que a Thoughtworks nomeou.

Se a disciplina se sustentasse por instrução, a ferramenta não precisaria existir. Ela é a confissão de que dizer "siga TDD" no prompt não faz o agente seguir TDD.

E há uma leitura mais útil nisso. Uma trava que não depende de o modelo concordar é a definição de guardrail, e não de instrução — a distinção está em onde travar antes de o agente agir. Se você quer TDD de verdade no loop, precisa de mecanismo, não de pedido. A pergunta que sobra é se vale o custo.

Böckeler propõe quatro substituições, e todas têm a mesma propriedade: medem resultado em vez de conformidade com o processo.

Mutation testing. Ele altera o código de propósito e verifica se algum teste quebra. Um teste que não detecta a mutação não estava verificando nada. É a resposta direta ao problema da cobertura: mede detecção, não execução.

Acesso a análise estática. Serve como gatilho contínuo de refatoração, ocupando o lugar que o passo de refatoração do ciclo deveria ocupar e não ocupa.

Cenários aprovados. Em vez de exigir teste antes do código, manter uma lista de cenários validados por humano que o sistema precisa satisfazer. A verdade vem de fora do modelo.

Revisão estrutural. Acompanhar contagem de arquivos e deriva de modularidade, para perceber quando o desenho está degradando — que é o problema que o TDD prometia evitar pelo caminho local e não evitou.

Testar e avaliar viraram sinônimo em conversa sobre agente, e não são. Teste verifica comportamento determinístico de código. Avaliar agente na tarefa real mede saída não determinística. As técnicas acima são da primeira família.

O que sobra em pé é curto, e cabe em quatro instruções.

Dê a verdade de fora. Especificação, exemplo de entrada e saída, bug reproduzido, contrato. O estudo de detecção mostrou que o contexto recuperado foi crítico, e é a diferença entre o teste verificar a especificação ou verificar a implementação.

Peça asserção sobre comportamento, não sobre estrutura. "Verifique que a função rejeita e-mail sem arroba" produz teste útil. "Escreva testes para esta função" produz o que o modelo achar que a função faz. O princípio é o mesmo do design de ferramentas para agentes: o que você entrega ao modelo define o teto do que ele consegue fazer.

Não use cobertura como meta. Se o número virar objetivo, o agente o alcança sem encontrar defeito — e agora existe medição mostrando que cobertura maior conviveu com detecção quatro vezes menor.

Rode mutation testing quando o custo justificar. É a única das medidas que responde a pergunta "esses testes servem para alguma coisa?" sem depender de julgamento.

A ordem importa. As três primeiras são de graça e mudam o resultado; a quarta custa tempo de máquina e vale para o código que não pode quebrar. As armadilhas de operação que aparecem no caminho estão em as armadilhas em projeto real, e a integração disso com commit e revisão em git com agente.

<!-- [PERSONAL EXPERIENCE] -->

Fui olhar o repositório antes de escrever esta seção, porque a resposta honesta exigia dado e não lembrança.

O blog tem 24 testes em cinco arquivos: frontmatter, guarda de link, newsletter, data de publicação e busca. Olhando o histórico do git, todos entraram no mesmo commit da funcionalidade que testam. Nenhum deles teve um commit vermelho antes. Nunca houve TDD aqui, nem por acidente.

E o caso mais recente é o mais interessante, porque contraria o que eu esperava. Os cinco testes da guarda de link foram escritos depois da implementação, e ainda assim produziram o benefício que o TDD promete: ao tentar testar, descobri que a função estava dentro de um módulo grande que o executor de testes não conseguia importar. A saída foi extrair a lógica para um módulo próprio, puro, sem dependência de runtime.

Ou seja: a pressão por testabilidade melhorou o desenho. Só que ela veio na hora de escrever o teste, não na hora de escrever o código primeiro. O ganho de desenho que o TDD reivindica apareceu sem o ritual.

O julgamento explícito: continuo escrevendo teste depois, e continuo achando que teste é inegociável. O que eu abandonei foi a ideia de que a ordem é o que produz o valor. E a parte incômoda é que 24 testes para um site deste tamanho é pouco — a lacuna não está no método, está na cobertura de decisões que ainda não têm nenhum teste.

Vale a pena impor TDD ao agente?

A medição disponível diz que não compensa. Em TDD inside the agent loop (agosto de 2026), o fluxo com TDD não produziu diferença claramente discernível contra o fluxo sem TDD, e consumiu de 3 a 8,5 vezes mais tokens. O teste continua valendo; a ordem em que ele é escrito não mostrou ganho.

Testes gerados por IA são confiáveis?

Melhores do que a discussão pública sugere. Num estudo com 29 bugs reais do BugsInPy, testes gerados por LLM detectaram falhas em 69% dos casos, contra 17,2% dos testes humanos de propósito geral. A condição decisiva foi o contexto recuperado: os testes eram bons porque tinham de onde tirar a especificação.

Cobertura alta significa teste bom?

Não. No mesmo estudo, os testes de LLM tiveram cobertura menor que a dos humanos (84,8% contra 88,5% em linha) e detectaram quatro vezes mais falhas. Cobertura mede se a linha executou, não se algo foi verificado quando ela executou.

O que é teste tautológico?

É o teste que afirma o que o código faz, em vez do que ele deveria fazer. Com agente, o risco aumenta porque o mesmo modelo que escreveu o código escreve o teste, e os dois herdam o mesmo entendimento — inclusive quando ele está errado.

Como impedir o agente de burlar o teste?

Instrução no prompt não basta, e a existência do tdd-guard, que bloqueia o agente quando ele pula teste ou implementa além do pedido, é a evidência disso. O que funciona é mecanismo: a verdade vir de fora do modelo, e a verificação rodar no ambiente.

Mutation testing vale o custo?

Vale para o código que não pode quebrar. É a única técnica da lista que responde diretamente se os testes detectam alteração de comportamento, que é a pergunta que a cobertura não responde. Para código de baixo risco, o custo de máquina raramente se paga.

• Teste de IA encontra defeito: 69% contra 17,2%, com cobertura menor.
• Cobertura é a métrica errada. Ela vê execução, não verificação.
• O ritual do TDD no loop do agente não mostrou ganho e custou de 3 a 8,5× mais.
• Quatro dos cinco modos de falha são o agente não executando a disciplina mandada.
• O teste tautológico é o modo grave: mesmo modelo, mesmo ponto cego.
• A verdade do teste precisa vir de fora do modelo.

Se você for mudar uma coisa depois de ler isto, tire a cobertura da posição de meta. É o número que trava merge, é o que menos diz sobre encontrar bug, e agora existe medição mostrando que ele pode subir enquanto a detecção despenca.