Passei um Mês Inteiro Corrigindo Testes — Aqui Está o Que Aprendi
Uma vez passei um mês inteiro… corrigindo testes.
Sem construir funcionalidades. Sem melhorar o produto. Apenas corrigindo testes.
Aqui está o que aconteceu.
Há alguns anos, apostei totalmente em testes
Mesmo código base. Mais de 1.000 testes. Unitários. Integração. End-to-end. Tudo.
No início, foi incrível.
Eu podia confiantemente:
- Validar lógica complexa com muita matemática
- Testar queries do banco sem medo
- Proteger fluxos críticos como todo o checkout do e-commerce
Parecia que nada poderia quebrar.
Mas então a realidade bateu
Cada pequena mudança começou a quebrar testes.
Não bugs reais. Apenas… testes.
Adicionou uma nova chamada de função interna? → Atualizar mocks
Refatorou algo inofensivo? → Corrigir 5 testes
Mudou a implementação mas não o comportamento? → Ainda quebrado
E de repente, cada funcionalidade tinha um custo extra: +1 dia inteiro apenas para testes
Agora multiplique isso por:
- Cada tarefa
- Até as pequenas
- Durante um ano inteiro
Foi quando percebi:
Eu não estava apenas escrevendo testes. Estava mantendo uma segunda base de código.
Minha conclusão controversa
Testes são poderosos. Eles podem te salvar.
Mas testar tudo tem um preço oculto: manutenção.
Se eu pudesse voltar atrás, faria diferente:
Eu testaria o que realmente importa.
Os fluxos principais. As coisas que, se quebrassem, matariam o produto.
Não tudo.
A mudança de jogo da IA
Agora, aqui está a parte interessante.
Isso foi há 3 anos, antes da IA realmente entrar no jogo.
Recentemente, tenho usado IA para gerar e corrigir testes.
E isso muda tudo.
A IA pode:
- Criar testes mais rápido
- Atualizar testes quebrados automaticamente
- Executar loops de correção com mínima intervenção humana
O que costumava levar dias… agora leva minutos.
Então talvez hoje, ter mais de 1.000 testes não seja mais o problema.
Mas uma coisa ainda importa
Sempre equilibre 👉 número de testes vs 👉 custo de manutenção
Porque no final, testes devem proteger sua velocidade, não matá-la.