Os 12 buracos da auditoria financeira e o teste que impede o décimo terceiro

Toda equipe tem aquela regra que todo mundo conhece e que ninguém consegue apontar onde está escrita. "Não escreva direto nessa tabela." "Sempre passe pela fachada." "Esse campo não pode ser alterado depois."

Regra assim tem uma característica: ela já foi quebrada. Você só ainda não descobriu.

O incidente

No nosso ERP, todo movimento financeiro deveria passar por uma fachada — a função que grava o pagamento, lança no razão e mantém o caixa coerente. A regra era conhecida, estava documentada e era respeitada. Quase sempre.

Doze vezes, não foi. Doze lugares no código faziam um insert direto em tabelas financeiras, pulando a fachada. Nenhum deles era malicioso; todos eram o caminho mais curto num dia corrido. E todos compilavam, passavam nos testes e funcionavam na tela.

O sintoma não aparece na hora. Aparece meses depois, quando o razão não bate com o extrato e ninguém consegue dizer desde quando.

Por que revisão de código não pega isso

Revisor humano é excelente para lógica e péssimo para invariante global. O insert direto parece certo localmente — é uma linha idiomática, com os campos certos, dentro de uma função que faz sentido. O que está errado nela não é visível no diff: é a relação dela com uma regra que vive em outro arquivo.

Multiplique por um repositório grande e a chance de o revisor lembrar da regra exatamente naquele diff é baixa. Não é falta de cuidado; é limite de atenção.

A solução: transformar a regra em teste

O que fizemos é simples ao ponto de parecer bobo. Um script varre o código-fonte procurando escrita direta nas tabelas financeiras e falha se encontrar alguma fora de uma allowlist.

Dois detalhes fazem esse teste funcionar onde outros falham:

A allowlist é a lista de fachadas, não a lista de exceções. Essa distinção é tudo. Uma lista de exceções cresce — cada pressa adiciona uma linha, e em um ano ela é maior que a regra. Uma lista de fachadas é arquitetura: adicionar uma entrada exige explicar por que existe um novo caminho legítimo para o dinheiro, e essa conversa acontece na revisão.

Ele roda antes do build. Testes estáticos assim custam cerca de um segundo. Colocá-los antes das etapas caras significa que quem quebrou a regra descobre imediatamente, e não depois de esperar o pipeline inteiro.

Não é o único

A ideia se espalhou porque o custo é ridículo perto do retorno. Hoje temos uma família desses testes:

• Invariantes de layout. Um hack de posicionamento tinha sido copiado em doze telas. Um dia alguém esqueceu, e a tela quebrou. O teste procura o padrão proibido e aponta o arquivo.
• Largura de diálogo. Uma sutileza de mesclagem de classes CSS fazia um valor padrão responsivo vencer o valor que o desenvolvedor escrevia. Vinte e quatro diálogos ficaram com o tamanho errado sem ninguém perceber. Hoje o teste recusa a classe manual e obriga a usar a propriedade.
• Repositório canônico. Depois que um deploy se perdeu em silêncio porque o push foi para o repositório errado, a origem passou a ser verificada — com aviso visível, não bloqueio.

Como escrever um desses

Um roteiro que funciona:

1. Espere a regra falhar uma vez. Escrever teste de invariante para regra hipotética é desperdício. A dor real é o que revela quais regras importam.
2. Escreva a asserção mais burra que detecta a falha. Busca por padrão de texto no código-fonte resolve a maioria dos casos. Não precisa de análise sintática.
3. Faça a mensagem de erro ensinar. Ela não deve dizer "violação da regra 4". Deve dizer o que fazer: use a fachada X; se você precisa mesmo de um caminho novo, adicione-o à lista e explique no PR.
4. Coloque no começo do pipeline.
5. Documente o incidente junto do teste. O comentário que diz "foi esquecer isto que criou os doze buracos" é o que impede alguém de excluir o teste daqui a dois anos por achá-lo paranoico.

O limite

Esse tipo de teste não substitui teste de comportamento, nem revisão. Ele cobre uma categoria específica: regra que é fácil de violar por acidente e cara de descobrir depois. Fora dessa categoria, vira burocracia.

E ele tem um custo real: falso positivo irrita e ensina a ignorar. Se o teste apontar demais, o problema é o teste — não a equipe.

O resumo

Uma regra de arquitetura que só existe na cabeça das pessoas tem prazo de validade: o próximo dia corrido. Transformá-la num script de um segundo que roda antes do build é a diferença entre uma convenção e uma garantia.

Os doze buracos foram tapados. O décimo terceiro não vai existir — não porque a equipe ficou mais cuidadosa, mas porque o caminho errado agora falha na hora.