Habilidades test-driven-development
📦

test-driven-development

Seguro

Dominar o fluxo de trabalho de desenvolvimento orientado por testes

Também disponível em: ZhanlinCui,DMJGilbert,Cycleaddict,davila7,DYAI2025,CodingCossack,Cygnusfear,obra

Escrever testes após o código não fornece prova de que eles realmente testam algo. Esta habilidade impõe o ciclo Vermelho-Verde-Refatorar onde todo teste deve falhar antes da implementação, garantindo que os testes verifiquem o comportamento real.

Suporta: Claude Codex Code(CC)
📊 70 Adequado
1

Baixar o ZIP da skill

2

Upload no Claude

Vá em Configurações → Capacidades → Skills → Upload skill

3

Ative e comece a usar

Testar

A utilizar "test-driven-development". Implement a function that retries failed operations 3 times

Resultado esperado:

  • Step 1 (RED): Write test 'retries failed operations 3 times'
  • Step 2: Run test - verify it fails because retry logic does not exist
  • Step 3 (GREEN): Implement minimal retry loop
  • Step 4: Run test - verify it passes
  • Step 5 (REFACTOR): Extract retry logic if needed

A utilizar "test-driven-development". Bug: Empty email accepted in form

Resultado esperado:

  • RED: test('rejects empty email') - expect error 'Email required'
  • Verify: Test fails - form currently accepts empty email
  • GREEN: Add validation check for empty email
  • Verify: Test passes, no regressions
  • Result: Bug fixed with test preventing regression

Auditoria de Segurança

Seguro
v1 • 2/25/2026

This skill contains only markdown documentation explaining test-driven development methodology. All 57 static analyzer findings for external_commands are false positives - the detected backticks are markdown code fences (```) used for syntax highlighting, not Ruby shell execution. The 6 cryptographic algorithm findings and reconnaissance detections are also false positives from pattern matching on documentation text. No executable code, network calls, or filesystem operations exist in this skill.

2
Arquivos analisados
674
Linhas analisadas
0
achados
1
Total de auditorias
Nenhum problema de segurança encontrado
Auditado por: claude

Pontuação de qualidade

38
Arquitetura
100
Manutenibilidade
87
Conteúdo
23
Comunidade
100
Segurança
91
Conformidade com especificações

O Que Você Pode Construir

Desenvolvimento de novas funcionalidades

Use TDD ao implementar novas funcionalidades para garantir que cada função tenha testes correspondentes que provem o comportamento correto antes do commit

Correção de bug com prevenção de regressão

Escreva um teste falho que reproduza o bug primeiro, então implemente a correção, garantindo que o bug não possa regredir

Refatoração com confiança

Use a suite de testes existente para verificar que o comportamento permanece inalterado durante a reestruturação ou otimização do código

Tente Estes Prompts

Ciclo TDD básico 
I need to implement [feature]. Help me write a failing test first that describes the expected behavior, then guide me through Red-Green-Refactor.
Correção de bug com TDD 
Bug: [describe bug]. Help me write a test that reproduces this bug (should fail), then implement the minimal fix to make it pass.
Revisão de qualidade de teste 
Review my test for [function]. Does it test real behavior or mock behavior? Is the test name clear? Does it test one thing?
Verificação de anti-padrão TDD 
action]. Check ifI'm about to [ this violates TDD principles. Am I testing mock behavior? Adding test-only code? Mocking without understanding?

Melhores Práticas

  • Sempre assista o teste falhar antes de implementar - isso prova que o teste realmente testa algo
  • Escreva código mínimo para passar o teste - sem funcionalidades extras, sem sobre-engenharia
  • Exclua o código de implementação se você pular o ciclo TDD e começar novamente com testes primeiro

Evitar

  • Escrever código de implementação antes do teste existir
  • Testar comportamento simulado em vez de comportamento real de código
  • Adicionar métodos apenas para teste às classes de produção

Perguntas Frequentes

E se eu já escrevi o código de implementação?
Exclua-o. O tempo já foi gasto. Reescreva usando TDD começando com um teste falho. Manter código não verificado é dívida técnica.
Posso escrever testes após a implementação?
Não. Testes escritos após passam imediatamente, não provando nada. Você testa o que construiu, não o que é necessário. TDD requer teste-primeiro.
E se o código for simples demais para testar?
Código simples também quebra. Um teste de 30 segundos previne bugs futuros. Se vale a pena enviar, vale a pena testar.
Como lidar com código existente sem testes?
Adicione testes para o comportamento existente antes de fazer alterações. Teste o comportamento atual primeiro, então use TDD para novas funcionalidades.
E se minha configuração de teste for muito complexa?
Testes complexos indicam design complexo. Simplifique a interface, extraia helpers, ou use injeção de dependência.
Quando posso pular o TDD?
Apenas para protótipos descartáveis, código gerado ou arquivos de configuração. Para código de produção, sempre use TDD, a menos que seu parceiro humano aprove uma exceção.

Detalhes do Desenvolvedor

Autor

sickn33

Licença

MIT

Repositório

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/test-driven-development

Referência

main

Estrutura de arquivos

📄 SKILL.md

📄 testing-anti-patterns.md