Ideia principal

Quem escreveu o próprio código o segura pela memória: sabe o que decidiu, onde tomou um atalho, quais partes se tocam. Quando o código é produzido por um assistente à razão de dezenas de commits por dia, essa memória não existe. Restam telas que funcionam, um repositório que ninguém leu por inteiro e partes que você não saberia explicar em voz alta.

O que sobra nessa situação são os testes. Um projeto montado em poucos dias pode ter várias centenas deles; o assistente os roda de novo com muita frequência, e na maior parte do tempo nada quebra. Quando algo quebra, o teste não diz apenas que há um problema: ele diz qual comportamento esperado deixou de ser respeitado, ou seja, ele localiza, enquanto a tela quebrada só sinaliza.

O teste, aqui, não é uma garantia de qualidade no sentido habitual. É o único instrumento que permite manter uma pegada num sistema cuja memória de construção você não tem.

Por que isso importa

Isso muda o argumento com que se defendem os testes diante de alguém que não programa. "Testes são boa prática" não pesa nada contra a velocidade; "sem eles, você não tem como saber o que a última alteração acabou de quebrar num código que você não leu" se entende na hora.

Também aponta o que deve ser exigido em primeiro lugar de um assistente a quem se confia a produção: não a cobertura por ela mesma, mas a existência de uma rede que torne o sistema interrogável depois.

Nuances e limites

O ponto de apoio não é um controle. Os testes só detectam o que descrevem: não veem o desabamento em volume real, nem as falhas de segurança, nem uma arquitetura que se torna impraticável de evoluir.

E a exigência é dosada. Uma ferramenta interna bem simples, de baixo risco e vida curta, não pede uma estratégia de testes completa — a questão volta a ser a da amplitude.

Questões em aberto

• Num código que você não escreveu, como saber se o conjunto de testes cobre os comportamentos que importam, e não os que eram fáceis de escrever?