Neste artigo
Quando o agente de IA escreve o código e o tempo é curto, a ordem de cobertura é por consequência do erro, não por percentual: autorização primeiro, dinheiro segundo. Migração de dado terceiro, e só então o resto. Se um desses três quebrar em produção, o problema deixa de ser técnico e vira cliente ligando.
Por que cobertura percentual engana aqui?
Agente gera teste com facilidade, e é aí que mora a armadilha: dá pra chegar a 80% de cobertura numa tarde, com testes que só confirmam o caminho feliz.
Cobertura mede linha executada, não risco coberto. Um projeto com 85% de cobertura e nenhum teste negativo de autorização está menos seguro que um com 30% que cobre exatamente os pontos onde o erro custa dinheiro.
Então a pergunta não é quanto do código está coberto, é quais falhas eu não posso descobrir em produção.
Em que ordem testar, e o que cada nível cobre?
| Prioridade | O que testar | Se falhar em produção |
|---|---|---|
| 1 | Autorização entre tenants e papéis | Cliente lê dado de outro cliente |
| 2 | Pagamento, cobrança, crédito | Cobra errado ou não cobra |
| 3 | Migração de dado | Perda sem volta |
| 4 | Fluxo crítico do produto ponta a ponta | Produto não entrega o que vende |
| 5 | Integração com terceiro | Quebra quando o outro lado muda |
| 6 | Resto do CRUD | Chato, corrigível no dia |
| Fonte: 80% de cobertura só no caminho feliz não cobre os três primeiros níveis, apurado em setembro de 2026. | ||
Os três primeiros eu escrevo ou reviso pessoalmente. Do quatro pra baixo, o agente escreve e eu leio por amostragem.
Por que o teste negativo é o que mais vale?
Teste positivo confirma que funciona pra quem pode. Teste negativo confirma que não funciona pra quem não pode, e é sempre o que falta.
// esse o agente escreve sozinho
it('dono le o proprio projeto', ...)
// esses precisam estar no pedido
it('tenant B recebe 404 lendo projeto do tenant A', ...)
it('tenant B recebe 404 editando projeto do tenant A', ...)
it('membro sem papel recebe 403 na rota de admin', ...)
it('id inexistente recebe 404, nao 500', ...)
it('convite expirado e recusado', ...)Repare que dois tenants precisam existir no seed. Sem isso o teste de isolamento não é escrevível, e é por isso que eu peço seed com dois tenants desde a primeira migration, como está em banco de dados e migrations com agentes de IA.
Por que dinheiro tem regra própria?
Tudo que envolve valor merece teste dedicado, porque erro aqui não é bug, é prejuízo ou processo.
O que eu sempre cubro: arredondamento em inteiro de centavos, moeda e conversão quando houver, idempotência de webhook de pagamento, e o que acontece quando o provedor responde duas vezes o mesmo evento.
Idempotência é a que o agente mais esquece. Provedor de pagamento reenvia webhook, e sem chave de idempotência você credita o mesmo pagamento duas vezes. Isso não aparece em teste feliz nenhum.
Como pedir a suíte ao agente?
Escreva os testes de projects.
Obrigatorios, alem do caminho feliz:- isolamento: tenant B nao acessa recurso do tenant A (404)
- papel: membro nao acessa rota de admin (403)
- entrada invalida: id inexistente -> 404, payload torto -> 422
- borda: lista vazia, pagina alem do fim, limite maximo
Use os 2 tenants do seed. Nao mocke o repositorio nos testes
de autorizacao: eles precisam bater no banco de verdade.A última linha importa. Teste de autorização com repositório mockado testa o mock, não o isolamento. Já vi suíte inteira verde com vazamento real embaixo, porque o mock devolvia o que o teste esperava.
Quando parar de escrever teste?
Meu critério de pronto: os três primeiros níveis cobertos com teste negativo, fluxo crítico passando de ponta a ponta, e suíte rodando em tempo que não desestimula rodar. Suíte de dez minutos ninguém roda antes do commit, e suíte que não roda não protege nada.
O que mais perguntam sobre isso?
TDD com coding agent funciona?
Funciona bem quando a interface já está definida, porque o teste vira uma spec executável e o agente tem alvo claro. Funciona mal quando você ainda está descobrindo o formato, aí o teste vira retrabalho.
Posso deixar o agente escrever teste do próprio código?
Pode, com uma ressalva grande: ele tende a escrever teste que passa com o código como está, incluindo o comportamento errado. Por isso os casos negativos vão no pedido, não na inspiração dele.
E teste de carga?
Depois dos funcionais, e só quando existir usuário de verdade para dimensionar. Antes disso é chute. O checklist do que olhar antes de subir está em checklist de segurança antes de produção.
