Livro de test-driven development ainda vale a pena com a IA escrevendo os testes?

Fala aí, beleza? Se o agente cospe a suíte de testes inteira em segundos, pra que ler um calhamaço sobre testar?

A pergunta é honesta, o incômodo é real

Só que o Kent Beck, autor do livro fundador do assunto, aponta pro lado contrário: em entrevista ao The Pragmatic Engineer, em 2025, ele chamou TDD de "superpower" justamente no trabalho com agentes de IA, porque a suíte é o jeito prático de impedir que o agente introduza regressão

E aí vem a parte engraçada: o mesmo agente NÃO quer fazer TDD

Nas palavras dele: "The genie doesn’t want to do TDD. It wants to write the code and then write tests that pass."

Ou seja, a ferramenta que te entrega o teste de graça é a mesma que inverte o ciclo sem te avisar

Bora destrinchar o que o livro entrega que o assistente não entrega, e o que virou dispensável de vez

O que o livro entrega e o que o assistente entrega

A comparação justa não é "quem escreve o teste mais rápido", porque essa disputa já acabou

É "quem sabe se o teste presta"

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Repara numa coisa: quase toda linha da coluna da direita é sobre JULGAMENTO, não sobre digitação

E tem uma armadilha que o Beck cravou no Canon TDD, publicado em dezembro de 2023, que qualquer pessoa comete em 10 segundos com o agente do lado: rodar o código, ver o valor que saiu, copiar esse valor e colar no campo do valor esperado

O teste fica verde na hora

E morre ali a dupla checagem, que é de onde vem boa parte do valor de validação do TDD

Esse é o tipo de erro que nenhum teste verde vai te contar

E os testes automáticos de cobertura, resolvem?

Um trabalho de fevereiro de 2026 sobre geração adversarial de testes descreve o trade-off que ainda está de pé: abordagens baseadas em busca alcançam alta cobertura, mas produzem testes de baixa legibilidade, enquanto os métodos baseados em LLM geram testes mais legíveis e sofrem com cobertura e compilabilidade baixas

E o mesmo trabalho aponta que pouca atenção foi dada à robustez na detecção de bugs em casos de canto

Tradução prática: escolha seu veneno, e nos dois casos alguém precisa saber ler o resultado

O que virou dispensável e o que ficou mais caro de não saber

Vamos ser honestos, porque tem coisa que a IA aposentou mesmo

Virou dispensável:

• decorar sintaxe de framework de teste (isso o agente resolve melhor que sua memória)
• digitar arrange, act e assert na mão, linha por linha
• montar mock na unha pra uma dependência besta
• criar caso repetitivo de tabela, aquele com 12 variações do mesmo cenário

Ficou MUITO mais caro de não saber:

• revisar uma suíte que passa inteira e não detecta nada (o famoso verde bonito e vazio)
• decidir contrato e granularidade: o que é uma unidade aqui, o que fica de fora, o que é responsabilidade do teste de integração
• segurar o agente no ciclo em vez de deixar ele escrever o código primeiro e o teste depois, pra justificar o que já fez
• reconhecer quando o teste está checando a implementação em vez do comportamento

O relatório DORA 2025 (State of AI-assisted Software Development) dá o pano de fundo pra isso: a adoção de IA chegou a 90% dos profissionais, alta de 14 pontos sobre o ano anterior, e mais de 80% dizem que a IA aumentou a produtividade deles

Agora se liga no contraste: sobre confiança no código gerado, só 24% confiam muito (4% "great deal" mais 20% "a lot"), e 30% confiam pouco ou nada

Quase todo mundo usa, poucos confiam

E a tese central do DORA é a que interessa aqui: a IA funciona como AMPLIFICADOR do sistema que já existe, não como conserto

Time forte fica melhor, time com processo fraco entrega trabalho ruim mais rápido

O livro de TDD entra exatamente aí: ele não é sobre escrever teste, é sobre ter o critério que a IA vai amplificar

O que aprendi tentando fazer a IA acertar de primeira

Eu não vim aqui falar de leitura, vim falar de um problema que eu vivi na prática do outro lado, no planejamento

Quando você toca um projeto no vibe coding solto, o começo voa

Depois ele empaca em coisa pequena, o consumo de tokens sobe e a regra de negócio precisa ser reescrita toda vez que entra uma funcionalidade nova

É um corpo sem cabeça: a ideia é boa, mas ninguém está conduzindo, e a IA escolhe stack, feature e visual por conta própria (pedi algo sóbrio e premium uma vez, veio um negócio visualmente exagerado, kkk)

O que resolveu pra mim foi planejar em 3 documentos antes de programar: requisitos (o que o app faz), design (como vai ser construído) e lista de tarefas (a ordem de execução)

São 3 etapas antes de escrever a primeira linha, e a minha régua pra decidir se o projeto pede isso é simples: mais de 3 prompts, ou tem autenticação, pagamento, perfis de usuário e dashboard? Então pede

E olha a semelhança com o TDD: a lista de cenários do Canon TDD é a mesma ideia da lista de tarefas

Alguém precisa dizer o que existe pra fazer ANTES do agente começar a produzir

Porque o critério que o livro ensina é o mesmo critério que você precisa pra escrever a especificação

Sem ele, você só aprova o que o agente propôs, sem ter como julgar

E julgar importa porque o Beck descreve o assistente como um "unpredictable genie": augmented coding é um processo não determinístico e sensível às condições iniciais, com resultados diferentes mesmo em prompts aparentemente idênticos

Gênio imprevisível não se controla com esperança, se controla com trava

Tem um custo nisso, e eu não vou esconder: planejar assim gasta mais token na largada, e pra projeto pessoal que ninguém vai usar isso pode ser queima de token à toa

Se você acompanha esse custo de perto, já falei sobre o preço do Claude Code em 2026 e sobre os limites do plano gratuito do Kimi K3, que é onde a conta costuma apertar primeiro

No vídeo abaixo eu mostro esse método de planejamento em 3 etapas aplicado num projeto real, um gerador de QR code com área logada, com os documentos escritos à mão antes de qualquer prompt de código

Qual livro de test-driven development resolve qual lacuna

Não existe UM livro, existe a lacuna que você tem

Repara que só o primeiro é sobre o ciclo

Os outros dois da Manning são sobre CRITÉRIO, que é exatamente o buraco que o agente deixa aberto

E o da Casa do Código resolve outra lacuna, que é barreira de idioma e exemplo fora da sua stack

Para quem vale a leitura hoje e para quem não vale

Veredito em três perfis, sem enrolação

Vale muito pra quem já delega geração de teste ao agente e não sabe julgar o que voltou

Aqui o custo do livro se paga na primeira suíte falsa que você desmascara, aquela verdinha que não mata mutante de borda nenhum

Começa pelo Khorikov, que é onde mora o critério de qualidade do teste

Vale pra quem lidera revisão de código num time que adotou IA

Se a IA amplifica o sistema que já existe, quem define o padrão de revisão define o teto do time inteiro

Aqui eu iria de Aniche no Effective Software Testing, por causa da parte de derivar caso a partir dos requisitos e decidir cobertura

Não vale como leitura mecânica pra quem só quer sintaxe de framework: isso o agente entrega mais rápido e sem você virar a noite

E não vale pra quem vai ler e não aplicar em código próprio, porque TDD não é conhecimento declarativo, é hábito de mão

Tem uma frase do Beck que resume o momento melhor que qualquer parágrafo meu: "O valor de 90% das minhas habilidades caiu para US$ 0. A alavancagem dos 10% restantes subiu 1000x", publicada por ele no X em abril de 2023

Critério de teste tá nos 10%

Conclusão

O livro de test-driven development não ficou obsoleto, ele mudou de função: era manual de digitação, virou manual de julgamento

Próximo passo concreto, e dá pra fazer hoje:

1. Pegue um item pequeno e rode o Canon TDD nele: lista de cenários, um item vira teste executável, código passa, refatora se valer, repete até a lista acabar
2. Mantenha a lista de cenários FORA do agente, escrita por você: é ela que decide quando parar, e o agente não tem essa lista
3. Nunca copie o valor calculado pelo código e cole no campo do valor esperado (o erro comum aqui é achar que o verde valida algo: ele só valida que o código concorda consigo mesmo)
4. Use a suíte como trava contra regressão do agente, e desconfie na hora que um teste que falhava simplesmente sumiu do repositório

Pra uma leitura curta de apoio, o Google Cloud tem uma página que amarra o achado do DORA 2025 à prática de TDD, chamada "How test-driven development amplifies AI success"

E aí, tu já pegou o agente apagando teste que falha? 😅

Até o próximo post!