No início de 2022, tomei uma decisão silenciosa: parei de escrever testes unitários para a maioria dos projetos WordPress e Node que passavam pela Seahawk. Sem alarde. Nenhum post no blog sobre isso. Eu simplesmente... parei. A justificativa era sólida, eu pensava, estávamos entregando 15 a 20 sites de clientes por mês, tinha três outros desenvolvedores em rodízio, e os testes que eu escrevia pareciam documentação que ninguém lia. O QA manual pegava os bugs reais. Testes eram teatro.
Avançando para o final de 2023. GitHub Copilot estava no meu editor há cerca de oito meses. Eu também tinha começado a usar Cursor para o lado para qualquer coisa greenfield. A velocidade era genuinamente notável. Mas algo começou a acontecer. Bugs apareciam em lugares que eu não tinha tocado. Lógica que parecia correta estava errada em edge cases que nunca pensei em verificar. E a pior parte, a IA não tinha ideia de que estava errada. Ela escrevia o código quebrado com a mesma indentação confiante que sempre faz.
Foi aí que peguei os testes de novo.
---
O Período em que Larguei os Testes (E Por que Fazia Sentido Na Época)
Resposta honesta? Para um certo tipo de projeto, pular testes foi a decisão certa. Se você está construindo um site de brochura de cinco páginas em WordPress, escrever testes PHPUnit para um plugin de formulário de contato é teatro. Defendo isso.
O pão de cada dia da Seahawk por muito tempo foi exatamente esse trabalho, alto volume, complexidade relativamente baixa, escopo bem definido. Um cliente passa você um arquivo Figma, você constrói, você faz QA, você entrega. Os feedback loops eram curtos. Se algo quebrava, você sabia em poucas horas. Escrever testes para esse contexto é o equivalente do desenvolvedor de laminear uma nota Post-it.
Mas generalizei essa lição muito agressivamente. Comecei a tratar todos os projetos como sites de brochura. Até mesmo aqueles com fluxos de checkout WooCommerce customizados. Até mesmo o dashboard fintech que construímos no início de 2023 para um cliente em Frankfurt, REST API completamente customizada, autenticação JWT, três níveis diferentes de permissão de usuário. Sem testes. Apenas "QA manual cuidadoso." Isso foi arrogante, e nos pegou.
O projeto Frankfurt foi lançado com um bug de permissões que permitia usuários de nível editor consultar dados de nível admin sob uma combinação específica de filtros. Não pegamos até o time interno rodar uma revisão de segurança seis semanas após o lançamento. Envergonhador. Corrigível. Mas o tipo de coisa que um teste de integração básico teria sinalizado antes mesmo de abrirmos um pull request.
---
O Que As Ferramentas de IA Para Código Realmente Mudaram
Aqui está a coisa que a maioria das pessoas perde quando fala sobre Copilot ou Cursor ou seja qual for o modelo em alta este mês: o código parece estar certo. Esse é o problema.
Quando um desenvolvedor junior escreve código bugado, você costuma ver a incerteza nele. Nomes de variáveis estranhos, um comentário que diz // não tenho certeza disso, uma função que é claramente copiada duas vezes. O código telegafa sua própria fragilidade. Código de IA não. É estilisticamente consistente, bem nomeado, e estruturado de um jeito que lê como intencional. A confiança é inteiramente cosmética.
Estudos do grupo Human-Computer Interaction de Stanford sinalizaram que desenvolvedores usando assistentes de IA tendem a confiar demais em código gerado na primeira leitura. Isso combina com minha própria experiência. Eu daria uma olhada em uma função de 40 linhas que Copilot tinha escrito, pensaria "sim, é basicamente o que eu teria escrito," e seguia adiante. Às vezes funcionava. Às vezes tinha silenciosamente entendido mal o que eu realmente precisava.
O modo de falha específico que eu continuava encontrando: lógica condicional ao redor de casos extremos que a IA não tinha razão para antecipar. Ela escrevia uma função que tratava o caminho feliz perfeitamente e depois falhava silenciosamente em entradas null, arrays vazios, ou formatos de data não-padrão. Coisas que teriam levado trinta segundos para eu pensar se tivesse escrito o código eu mesmo, porque teria estado pensando enquanto digitava.
A Armadilha da Velocidade
Há uma armadilha real de produtividade aqui. A IA te deixa rápido. Rápido parece ser bom. Você começa a fazer deploy mais rápido e começa a revisar menos cuidadosamente porque a velocidade parece ser evidência de qualidade. Não é. Velocidade e correção não são correlacionadas quando você está usando um modelo de linguagem.
Coloquei aproximadamente 40% mais features em um projeto de cliente em setembro passado do que teria conseguido sem assistência de IA. O projeto também teve mais bugs pós-lançamento do que qualquer coisa que tivesse feito deploy em dois anos. Não foram bugs catastróficos. Mas irritantes. Do tipo que desgasta a confiança do cliente.
---
Por Que Testes Funcionam Diferente Agora (Com IA no Fluxo)
Quando voltei aos testes, não voltei ao fluxo antigo. Escrever testes primeiro, depois implementação, depois revisão de código assistida por IA, esse é o loop em que me estabeleci agora.
O interessante é que IA é na verdade excelente em escrever testes, de uma forma que nem sempre é excelente em escrever lógica de aplicação. Dê ao Copilot uma assinatura de função bem definida e peça para gerar um test suite e ele vai produzir cobertura de casos extremos que teria levado vinte minutos para escrever manualmente. Ele imagina caminhos infelizes bem quando a tarefa é especificamente "encontre maneiras disso quebrar".
Então eu meio que inverti a coisa. Eu escrevo a especificação de testes. IA completa os casos de teste. Depois IA escreve a implementação. Depois eu leio a implementação através da lente desses testes, em vez de apenas ler o código frio.
É mais lento do que pure vibe-coding. Mas é mais rápido do que o fluxo antigo de escrever tudo manualmente, incluindo testes. E fez deploy de zero bugs de permissões desde Frankfurt.
As Ferramentas que Estou Realmente Usando
- [Vitest](https://vitest.dev) para qualquer coisa JavaScript ou TypeScript. Substituiu Jest inteiramente para mim no ano passado, a config é mais sensata e o watch mode é rápido.
- PHPUnit ainda, para WordPress e trabalho PHP customizado. Nada substituiu.
- O atalho "test this function" do Cursor, genuinamente uma das features single mais úteis em qualquer editor que usei.
- GitHub Actions para CI. Tests rodam a cada push para main. Leva cerca de 90 segundos na maioria dos projetos.
---
O Argumento Contra Tests (Steel-Manned)
Quero dar a essa posição uma oportunidade justa porque a sustentei por quase dois anos.
O argumento real não é "testes são inúteis." É "testes têm um custo e muitos projetos não justificam esse custo." Escrever e manter uma suite de testes leva tempo. Em um projeto com ciclo de vida curto, um microsite de campanha, uma landing page de marketing, um protótipo de hackathon, esse investimento de tempo tem zero retorno. O projeto estará morto antes dos testes te salvarem de algo.
E há um ponto mais sutil: testes ruins são piores que nenhum teste. Uma suite de testes que passa porque os testes são tautológicos (você está essencialmente testando que sua função retorna o que você disse que retorna) te dá falsa confiança. Já vi isso em agências. Desenvolvedores escrevendo testes que sempre passam porque ninguém questionou o que eles realmente estavam verificando.
Martin Fowler escreveu bem sobre isso, percentuais de cobertura não são uma medida de qualidade de teste. Um número de cobertura de 90% pode mascarar uma suite completamente vazia.
Então: não teste tudo. Não teste porque parece profissional. Teste porque você identificou lógica que é estrutural e seria caro quebrar.
---
O Que Eu Testo Agora (E O Que Não Testo)
Aqui está a decisão real em que cheguei depois dos últimos oito ou nove meses:
Eu testo:
- Qualquer função que lida com dinheiro, permissões ou transformação de dados
- Qualquer endpoint de API que não seja um pass-through CRUD direto
- Lógica de negócio customizada onde o cliente especificou o comportamento exato por escrito
- Qualquer coisa que uma IA escreveu e que eu não li completamente linha por linha
Eu não testo:
- Renderização de UI (Testes de snapshot nunca me salvaram uma vez em nove anos. Nem uma.)
- Wrappers de API de terceiros onde o comportamento externo está fora do meu controle
- Scripts únicos que rodam uma vez e são deletados
- WordPress hooks padrão a menos que estejam fazendo algo incomum
Pronto. Nenhuma grande filosofia. Só uma lista baseada em onde já fui queimado.
---
O Workflow Que Realmente Funciona Para Mim
Como algumas pessoas pediram em comunidades Slack onde estou, aqui está a sequência real:
- Escreva um comentário de especificação breve no topo do arquivo, o que este módulo faz, o que não faz, casos extremos que você já conhece.
- Peça ao Cursor para gerar casos de teste a partir desse comentário antes de escrever qualquer implementação.
- Revise aqueles casos de teste. Delete os desnecessários. Adicione qualquer um que a IA tenha deixado passar.
- Deixe o Copilot ou Cursor escrever a implementação.
- Execute os testes. Eles vão falhar. Corrija a implementação (não os testes).
- Leia o diff antes de fazer push, código assistido por IA ainda precisa de uma passada humana.
O passo 6 é inegociável. Peguei três bugs genuinamente graves nos últimos quatro meses só lendo o diff lentamente antes de fazer push. Nada de genial. Só lendo.
O framing original de TDD de Kent Beck nunca foi sobre 100% de cobertura ou metodologia perfeita. Era sobre construir um loop de feedback rápido o suficiente para pegar erros antes de eles se comporem. Essa ideia, loops de feedback rápidos, é mais relevante agora do que era em 2003. Porque a IA comete erros mais rápido do que qualquer desenvolvedor que já contratei.
---
FAQ
Isso desacelera sua velocidade de entrega?
Em torno de 10 a 15% em projetos complexos. Em projetos simples, talvez nada. A IA gera os testes tão rapidamente que o overhead é mínimo. Para projetos onde um bug custaria dinheiro real para corrigir após o lançamento (e a maioria dos projetos com dinheiro real se qualifica), esses 15% valem a pena cem vezes.
E o TypeScript? A tipagem forte não substitui um monte de testes?
Parcialmente. TypeScript pega uma classe inteira de erros em tempo de compilação que você costumava precisar de testes para encontrar. Mas tipos não testam lógica de negócio. Eles não verificam que sua função de cálculo de desconto aplica as regras certas para clientes atacadistas. Isso continua sendo com você.
Desenvolvedores juniores deveriam usar ferramentas de codificação com IA se não estão escrevendo testes?
Não. Opinião forte. Um desenvolvedor junior usando Copilot sem testes está essencialmente pilotando um avião no piloto automático sem entender como o piloto automático funciona ou como pousar manualmente. A IA vai produzir código que parece de nível sênior, o junior não vai saber em quais partes desconfiar, e você vai ter um incidente em produção eventualmente. Testes pelo menos dão a eles um mecanismo para verificar o output que estão aceitando.
Por que você parou de escrever testes em primeiro lugar, honestamente?
Burnout, parcialmente. E um período onde cada projeto era genuinamente simples e testes genuinamente não estavam gerando seu valor. O erro foi não notar quando a complexidade do projeto mudou e se ajustar de acordo. Essa é a lição real, não "sempre teste" ou "nunca teste", mas saber em qual categoria um projeto específico se encaixa.
---
Escrever testes não costumava parecer proteção. Parecia burocracia. A IA mudou isso. Não porque a IA é ruim — ela me tornou significativamente mais rápido — mas porque introduziu uma nova classe de erros confiantes, bem formatados e plausíveis que não consigo pegar lendo código da forma que costumava fazer. Os testes não são para a IA. São para mim. Uma função de forçar para pensar sobre o que realmente preciso que o código faça antes de aceitar o que quer que o modelo me entregue.
Gostaria de ter enquadrado isso assim dois anos atrás.
Leitura relacionada: How I Use Claude Code Daily as a Founder Who Still Ships, tools, and SEO.