tdd

Visão geral do tdd skill

tdd é um skill de Test-Driven Development para construir funcionalidades e corrigir bugs com o ciclo red-green-refactor. Ele é ideal para engenheiros que querem um guia prático de tdd que mantenha os testes alinhados ao comportamento, e não à implementação. Se você trabalha em uma codebase em que refatorações são frequentes, interfaces importam e testes frágeis estão atrapalhando o ritmo, este skill ajuda a escrever testes que continuam válidos mesmo quando o código muda.

A principal tarefa aqui é simples: transformar uma ideia bruta de funcionalidade em uma sequência segura de pequenos passos testáveis. O tdd skill é especialmente útil para automação de testes, testes de estilo integração e código que se beneficia de limites mais claros. Sua orientação mais forte é testar por meio de interfaces públicas e fazer mock apenas em fronteiras reais do sistema.

Para que serve o tdd

Use tdd quando você quiser um fluxo de trabalho test-first para comportamento novo, correções de bugs ou refatorações que precisam de uma rede de segurança. Ele funciona bem quando você já sabe o resultado esperado, mas ainda não sabe qual é o caminho mais limpo para implementá-lo.

O que torna este tdd skill diferente

O repositório não se resume a “escrever testes primeiro”. Ele propõe uma disciplina específica: evite cortes horizontais, prefira testes focados em comportamento e desenhe interfaces fáceis de testar. Isso torna o tdd skill mais útil do que um prompt genérico quando você precisa de testes duráveis, em vez de testes rápidos e frágeis.

Quando o tdd é uma escolha ruim

Se você precisa de um teste unitário rápido e pontual, de um script descartável ou de uma verificação muito baseada em mocks de chamadas internas, provavelmente este não é o melhor caminho. O skill é voltado a software que você espera refatorar, em que a qualidade dos testes importa mais do que a quantidade.

Como usar o tdd skill

Instale e carregue o skill

Use o comando de instalação do diretório para a etapa tdd install e, em seguida, abra primeiro o SKILL.md. Depois disso, leia tests.md, mocking.md, interface-design.md, refactoring.md e deep-modules.md para entender as regras que realmente moldam a qualidade da saída.

Dê ao skill um comportamento, não uma solução

O melhor uso de tdd começa com um resultado visível para o usuário, uma entrada e um resultado esperado. Uma boa formulação de prompt:

• “Adicione validação no checkout para que carrinhos inválidos retornem um erro claro e carrinhos válidos concluam o pagamento”
• “Corrija o bug em que e-mails duplicados criam duas contas”
• “Escreva testes para um fluxo de retry em uma API de pagamentos, usando a interface pública do serviço”

Uma formulação fraca:

• “Escreva testes para o checkout”
• “Torne este módulo mais testável”
• “Faça mock do banco de dados e verifique se a função foi chamada”

Siga o ciclo red-green-refactor

Comece com o menor comportamento observável, escreva um teste que falhe e prove isso, implemente o mínimo necessário para passar e então refatore mantendo o teste verde. Não agrupe todos os testes primeiro e a implementação depois; o skill alerta explicitamente contra cortes horizontais porque eles criam comportamento imaginado, e não comportamento testado.

Leia estes arquivos primeiro

Para execução prática, priorize:

• SKILL.md para a filosofia e o fluxo de trabalho
• tests.md para padrões bons e ruins de teste
• mocking.md para mock apenas nas fronteiras
• interface-design.md para deixar o código mais fácil de testar
• refactoring.md para o que melhorar depois do primeiro verde

Perguntas frequentes sobre o tdd skill

tdd é só para testes unitários?

Não. Este tdd skill prefere testes de estilo integração por meio de interfaces públicas, o que muitas vezes o torna melhor para automação de testes e teste de comportamento do que para setups isolados e muito centrados em unit tests.

Preciso fazer mock de tudo?

Não. Uma regra central deste tdd guide é fazer mock apenas em fronteiras do sistema, como APIs externas, tempo, aleatoriedade ou, às vezes, o sistema de arquivos ou o banco de dados. Não faça mock dos seus próprios módulos só para os testes passarem.

Iniciantes podem usar tdd?

Sim, desde que consigam descrever o comportamento esperado com clareza. A principal curva de aprendizado não é sintaxe; é escolher a fronteira certa e evitar testes baseados em detalhe de implementação.

Em que o tdd é diferente de um prompt normal?

Um prompt normal pode gerar testes que apenas compilam. O tdd skill é mais opinativo: ele incentiva testes guiados por comportamento, incrementos pequenos e um design de interface que mantém os testes estáveis durante refatorações.

Como melhorar o tdd skill

Comece com uma entrada mais precisa

Você terá resultados melhores com tdd quando incluir comportamento, fronteira e restrição. Por exemplo, diga “crie um remetente de e-mail com retry que use um wrapper real de serviço, mas faça mock do tempo e do provedor externo” em vez de “torne isso testável”.

Fique atento aos modos de falha mais comuns

Os erros mais comuns são fazer mock em excesso, testar métodos privados e escrever testes que descrevem como o código funciona em vez do que o usuário vê. Se o primeiro rascunho parecer dependente demais da implementação, revise o prompt para nomear a API pública e o resultado observável.

Itere do teste para o design

Depois da primeira saída, use as falhas para melhorar o design da interface: parâmetros menores, valores de retorno mais claros e menos efeitos colaterais. Se o código ainda parecer difícil de testar, o problema pode estar no formato da API, e não nos testes.

Peça alvos de refatoração depois de passar

Quando o comportamento já estiver coberto, peça ao skill para identificar duplicação, métodos longos, módulos rasos, feature envy ou primitive obsession. É aí que o tdd skill entrega valor extra: ele ajuda você a sair de “testes passando” para um design mais limpo que continue fácil de testar.