Quem escreve a funcionalidade não pode escrever o teste que a aprova

Teste verde é o sinal em que todo mundo confia. É um sinal honesto na maior parte das vezes: alguém escreveu o que o requisito pedia, alguém checou, a barra ficou verde e o trabalho seguiu.

Ele deixa de ser honesto no arranjo que virou padrão quando o código passou a sair de modelo: a mesma inteligência escreve a funcionalidade e escreve os testes dela. Se o modelo entendeu o requisito errado, o teste entendeu igual. Os dois erram juntos, na mesma direção, e nada fica vermelho.

Vi isso inteiro no Equity_Tracker, num caso que ficou com o nome de BDR failure mode: funcionalidade implementada fora do que o spec pedia, testes escritos pelo mesmo modelo, tudo passando. Desde então separo o papel, e a pergunta que essa separação responde é direta: quem testa o código deveria ser a mesma inteligência que escreveu o código?

Teste verde não prova que a funcionalidade está certa

O mecanismo é fácil de enunciar e quase impossível de enxergar de dentro. O teste não checa o requisito de forma independente; ele checa a leitura que o modelo fez do requisito. Quando essa leitura está torta, o teste nasce torto junto e confirma exatamente aquilo que deveria contestar.

No caso do Equity_Tracker nenhum teste falhou, e não havia bug para encontrar no sentido comum da palavra. O código fazia certinho o que o modelo tinha entendido. A intenção escrita no spec é que não estava sendo cumprida, e nenhum teste perguntava por ela.

Teste verde nesse cenário quer dizer uma coisa bem mais modesta do que parece: o código é consistente com o que o modelo pensou que devia fazer. Consistência interna não é conformidade com o spec, e confundir as duas é o jeito mais silencioso de entregar a coisa errada com a consciência limpa.

Um verificador que nunca lê a implementação quebra o ciclo

O padrão que uso é um subagente restrito, o test-verifier. Ele escreve testes de aceitação a partir de uma fonte só: a seção ## Acceptance Criteria do spec. Não lê o corpo da implementação, e não é informado de como o sistema resolveu o problema.

Depois de escrever, ele roda os testes contra o sistema já construído e devolve um veredito por critério: VERIFIED, FAILED: N/M ou BLOCKED. Não existe nota geral nem percentual de cobertura. Cada critério de aceitação sai marcado individualmente, e um critério bloqueado aparece como bloqueado em vez de se disfarçar de aprovado.

A independência não vem de desconfiar de um modelo em relação a outro. Ela é estrutural: a cegueira à implementação é a condição que impede o teste de herdar o mesmo mal-entendido. Um verificador com acesso ao código vai acabar escrevendo, sem nenhuma má intenção, o teste que aquele código passa.

A parede fica entre a forma e o comportamento

A parte difícil não é aceitar a regra. É desenhar onde ela passa. Cegueira total trava o verificador: sem saber o nome das funções nem o formato dos dados que entram e saem, ele não escreve teste nenhum, só chuta interface.

A linha que sobrou tem nome, shape-vs-behavior. O verificador pode ler assinaturas públicas, type stubs, definições de schema e de configuração — a forma da interface. Não pode ler corpos de implementação, que é onde mora o comportamento: a lógica que produz o resultado, o caminho escolhido para chegar nele.

Essa distinção não saiu de um documento de arquitetura. Ela precisou ser desenhada no meio de um teste ao vivo contra o spec do dashboard do Solo_Trader. Foi ali que ficou claro que o verificador precisava de alguma informação e não podia receber toda.

O verificador cego não diagnostica nada, e isso é de propósito

Recomendo esse desenho para qualquer funcionalidade cujo teste decide aceito ou não aceito, e recomendo com a fatura à vista. O verificador não diz por que um critério falhou: ele devolve FAILED: 2/5 e para ali. Ele também não julga qualidade de código — nome ruim, duplicação, função de duzentas linhas, nada disso entra no veredito, porque revisão de código é papel de outro agente com outra permissão de leitura.

O custo maior é o de velocidade. Escrever teste só a partir dos Acceptance Criteria, sem contexto nenhum de implementação, rende teste mais rígido e demora mais do que deixar quem já conhece o código escrever direto. Pago esse preço porque o que ele compra é a única coisa que o teste verde não dá sozinho: a chance de o resultado discordar de quem construiu.

Quem decide se o trabalho foi aceito não pode ter escrito o trabalho

A regra prática cabe numa linha: funcionalidade cujo teste decide aceito ou não aceito deveria ser testada por um agente que nunca viu como ela foi implementada.

Abro mão da separação no dia em que o mesmo modelo conseguir testar contra a intenção do spec sem contaminação do código que ele acabou de escrever. Nos dois casos que acompanhei de perto, o BDR failure mode do Equity_Tracker e o teste ao vivo contra o spec do Solo_Trader, não apareceu sinal disso.

Até lá a parede fica onde está, e ela cabe numa frase: ler a forma, nunca o comportamento.