Ideia principal

Escrever o teste primeiro e o código depois inverte a ordem habitual, mas o interesse não está na ordem. O teste descreve o quê — este é o comportamento esperado, isto é o que precisa continuar verdadeiro. O código descreve o como. O primeiro é, portanto, uma peça da especificação, escrita numa linguagem que a máquina consegue avaliar.

O que isso muda aparece com o tempo. O código vai ser refatorado, vai encontrar dados novos, outras funcionalidades vão ser acrescentadas em volta dele. Já o comportamento esperado fica fixado fora da memória de quem o implementou: se ele for quebrado, o teste quebra, de preferência na máquina do desenvolvedor ou em homologação, e não em produção.

O TDD não elimina os defeitos, não substitui a reflexão de produto e não transforma uma especificação ruim num bom produto. Ele faz uma coisa só, e ela é rara: torna uma parte da qualidade verificável antes de o código existir.

Camada trazida por "Ontology-Driven Design: e se a ontologia virasse a rede de segurança do código gerado por IA?" (2026-10-29). A mesma lógica de anterioridade pode se estender à parte do comportamento esperado que nenhum teste formaliza: o modelo de domínio. Antes que um agente como o Claude Code escreva o código de uma funcionalidade, a solicitação é confrontada com a ontologia do domínio — conceitos, regras, estados — e as contradições são resolvidas antes de serem codificadas. A ordem é a mesma do TDD; a garantia não é, já que o veredito vem de uma análise feita por um LLM e não de uma asserção determinística.

Por que isso importa

Isso tira a disciplina do campo da higiene técnica. Um teste escrito antes é um artefato de especificação e, portanto, um lugar onde produto e desenvolvimento podem chegar a um acordo sobre um comportamento — o que um documento em prosa não permite, por não ser avaliável.

Isso também desloca o custo dos testes: escritos depois, eles constatam o que o código faz; escritos antes, eles restringem o que ele vai precisar fazer.

Nuances e limites

A parte formalizável é estreita. Um teste diz que um comportamento é mantido, nunca que ele era o comportamento certo a buscar — a parcela da qualidade que depende do julgamento de produto continua inteira.

E a disciplina pressupõe que a gente saiba enunciar o comportamento esperado. Diante de uma especificação vaga demais, escrever o teste primeiro não esclarece nada: congela a ambiguidade em vez de resolvê-la.

Questões em aberto

• Que parte de uma verificação feita pelo modelo de domínio consegue atingir uma confiabilidade suficiente para fazer o papel de um teste, sem ter a garantia determinística dele?