Neste capítulo você vai aprender a colocar o Claude Code para trabalhar em toda a camada de testes do seu projeto: rodar a suíte e interpretar as falhas, gerar testes para código que ainda não tem nenhum, praticar desenvolvimento guiado por testes e medir cobertura sem cair em armadilhas. No capítulo oito, encerramos a correção de um bug criando um teste de regressão; agora você vai entender a técnica por trás daquele passo e aplicá-la de forma sistemática, com exemplos em Jest, para JavaScript, e em pytest, para Python.
Executando a suíte e lendo as falhas
O pedido mais simples também é o mais frequente: rodar os testes. Diga apenas: rode a suíte de testes e me diga o que falhou e por quê. O Claude Code procura o comando correto no package.json, no pyproject.toml ou no CLAUDE.md, pede aprovação para executá-lo e lê a saída completa. A vantagem em relação a rodar você mesmo está na interpretação. Em vez de trinta linhas de stack trace, você recebe um resumo do tipo: dois testes falharam, ambos no serviço de tarefas, porque a função agora retorna nulo em vez de lançar exceção.
Quando a saída é longa, peça filtragem explícita. Uma instrução como: rode o Jest e liste apenas os testes que falharam, com arquivo, linha e a diferença entre esperado e recebido, economiza janela de contexto e vai direto ao ponto. Em Python, o equivalente é: rode o pytest com saída curta e agrupe as falhas por causa provável. Se você suspeita que uma falha é intermitente, peça para executar três vezes seguidas e comparar os resultados, exatamente como fizemos com condições de corrida no capítulo anterior.
Um cuidado importante: uma falha nem sempre indica bug no código. Às vezes o teste estava errado desde o início, ou o comportamento mudou de propósito. Antes de aceitar qualquer correção, pergunte ao Claude Code qual dos dois casos ele acredita que ocorreu e por quê. Essa pergunta evita que ele corrija o teste para se adequar a um bug.
Gerando testes para código existente
Muitos projetos reais têm módulos inteiros sem nenhum teste. Aqui o Claude Code brilha, desde que a instrução seja precisa. Um pedido vago como escreva testes para o serviço de tarefas produz testes superficiais que apenas confirmam o caminho feliz, ou seja, o cenário em que tudo dá certo. Um pedido bom lista o que deve ser coberto:
- Ouça o áudio com a tela desligada
- Ganhe Certificado após a conclusão
- + de 5000 cursos para você explorar!
Baixar o aplicativo
Crie testes unitários em Jest para o arquivo de serviço de tarefas, referenciado com arroba, no mesmo estilo do teste de usuários já existente. Cubra: criação com dados válidos, título vazio, título com mais de duzentos caracteres, prazo no passado, prazo no limite exato de hoje e chamada com usuário inexistente. Não altere o código de produção. Os testes devem passar ao final.
Repare nos casos de borda: limites exatos, valores vazios, entradas inválidas e recursos que não existem. Se você não os listar, é provável que a inteligência artificial teste só o óbvio. Uma técnica útil é pedir primeiro uma lista de casos, sem escrever código, revisá-la e só então autorizar a implementação. Isso segue o princípio de plano antes da execução do capítulo quatro.
Para testes de integração, aqueles que exercitam vários componentes juntos, indique o que é real e o que é simulado. Em uma API com banco de dados, por exemplo: use o banco de testes configurado no CLAUDE.md, faça requisições reais com a biblioteca supertest e limpe as tabelas entre os testes. Antes de rodar qualquer rotina que apague tabelas, confirme com seus próprios olhos que a variável de conexão aponta para o banco de testes, e nunca para produção: um comando de limpeza disparado na base errada destrói dados reais e não tem desfazer. Em Python, o equivalente seria usar fixtures do pytest, que são funções de preparação reutilizáveis, com um banco SQLite em memória.
Desenvolvimento guiado por testes
O desenvolvimento guiado por testes, conhecido pela sigla TDD, inverte a ordem habitual: primeiro o teste, depois o código. Com o Claude Code o fluxo funciona muito bem, mas exige disciplina na instrução. O ciclo tem quatro passos.
- Peça que ele escreva os testes para o comportamento desejado, sem implementar nada ainda, deixando explícito que a implementação não existe.
- Peça que rode a suíte e confirme que os novos testes falham pelo motivo certo, isto é, porque a função não existe ou retorna o valor errado, e não por erro de sintaxe no próprio teste.
- Peça que implemente o código mínimo para passar, sem tocar nos arquivos de teste.
- Peça que rode de novo e, se algo ainda falhar, ajuste apenas o código de produção até tudo ficar verde.
O ponto crítico é o terceiro passo. Sem a proibição explícita, a inteligência artificial às vezes percebe que é mais fácil editar o teste do que implementar a função corretamente. Portanto escreva algo como: os arquivos de teste não devem ser modificados; se você acredita que um teste está errado, pare e me explique. Você também pode reforçar isso no CLAUDE.md, como veremos adiante.
Um exemplo em Python. Suponha uma função de cálculo de desconto que ainda não existe. O pedido inicial gera algo assim:
import pytest def test_desconto_zero_para_valor_abaixo_do_minimo(): assert calcular_desconto(49.99) == 0 def test_desconto_dez_por_cento_no_limite_exato(): assert calcular_desconto(50.00) == pytest.approx(5.00) def test_valor_negativo_lanca_erro(): with pytest.raises(ValueError): calcular_desconto(-1)Note dois detalhes do exemplo: o import do pytest é obrigatório para usar o raises, e valores em dinheiro nunca devem ser comparados com igualdade exata em ponto flutuante. Use o approx, como acima, ou trabalhe com o tipo Decimal no código de produção.
Ao rodar o pytest, os três testes falham com erro de nome não definido, que é exatamente a falha esperada. Só então você autoriza a implementação. Quando a suíte fica verde, você tem uma função que faz o que os testes descrevem e nada além disso.
Para tarefas maiores, peça iteração automática: implemente e rode os testes em ciclo até todos passarem, mostrando cada diff antes de aplicar. No modo padrão com aprovação você ainda revisa cada alteração; no modo de aceitar edições automaticamente, as edições de arquivo são aplicadas sem confirmação, embora os comandos de terminal continuem pedindo aprovação, a menos que você já os tenha liberado. Use esse modo apenas com o trabalho salvo no controle de versão e em um branch separado, para poder descartar tudo com um comando se a iteração sair do rumo. Escolha conforme o risco da mudança.
Medindo e melhorando cobertura com critério
Cobertura de testes mede quais linhas do código foram executadas por algum teste. Peça: rode os testes com cobertura e liste os cinco arquivos com menor percentual, indicando quais funções não são exercitadas. Em Jest, isso usa a opção de coverage; em pytest, o plugin pytest cov. O Claude Code lê o relatório e aponta onde estão os buracos.
Evite a meta de cem por cento. Cobertura alta não significa teste bom: uma linha executada sem nenhuma verificação conta como coberta. Em vez de pedir para aumentar a cobertura para noventa por cento, peça: escreva testes para as funções de regra de negócio da pasta de serviços que ainda não têm nenhum, priorizando cálculos e validações; ignore arquivos de configuração e acessores triviais. Assim o esforço vai para onde um bug custaria caro.
Duas armadilhas dos testes gerados por inteligência artificial
A primeira armadilha é o teste que congela o comportamento atual. Quando você pede testes para código existente sem dizer qual é o comportamento correto, o Claude Code observa o que a função faz hoje e escreve asserções que confirmam exatamente isso, inclusive os bugs. O teste passa, mas não prova nada. Para evitar, descreva o comportamento esperado em termos de regra de negócio, e não em termos do código, e peça que ele avise se encontrar alguma discrepância entre a regra e a implementação.
A segunda armadilha é o excesso de mocks. Mock é um substituto falso para uma dependência, como um banco de dados ou um serviço externo. A inteligência artificial tende a simular tudo para que o teste rode rápido e isolado, mas se você simula o repositório, o validador e o formatador, o teste acaba verificando apenas que os mocks foram chamados. Peça explicitamente: simule apenas chamadas de rede externas; use o banco de testes real e as funções reais do projeto. Revise cada arquivo de teste gerado procurando a palavra mock e pergunte a si mesmo se aquela substituição era necessária.
Registrando os comandos de teste no CLAUDE.md
Tudo o que vimos funciona melhor quando o Claude Code sabe, sem perguntar, como rodar os testes. No capítulo cinco você aprendeu a estrutura do CLAUDE.md; agora adicione uma seção dedicada, curta e objetiva:
## Testes - Rodar tudo: npm test - Rodar um arquivo: npx jest caminho/do/arquivo.test.js - Cobertura: npm run test:coverage - Banco de testes: usa DATABASE_URL_TEST definida em .env.test - Nunca editar arquivos em tests/ para fazer um teste passar; explique o problema antes - Novos testes seguem o estilo de tests/usuarios.test.jsEm um projeto Python, substitua pelos comandos do pytest, do pytest cov e pelo caminho das fixtures. Com isso, o pedido para rodar os testes nunca dispara uma busca pelo comando certo, e a regra contra editar testes passa a valer em toda sessão, sem que você precise repeti-la.
Recapitulando
Você aprendeu a pedir a execução da suíte com saída filtrada e interpretação das falhas, a gerar testes para código existente listando casos de borda em vez de deixar a escolha para a inteligência artificial, a praticar desenvolvimento guiado por testes confirmando a falha antes de implementar e proibindo alterações nos testes, a iterar até a suíte ficar verde, e a usar cobertura como bússola e não como meta. Viu também as duas armadilhas mais comuns, testes que congelam bugs e mocks em excesso, e registrou os comandos e as regras de teste no CLAUDE.md para que valham em todas as sessões.
