스킬 tdd
📦

tdd

안전

Escrever testes usando desenvolvimento orientado a testes

또한 다음에서 사용할 수 있습니다: Benny9193

Escrever testes após o código criar sistemas frágeis que quebram em refatorações. Esta skill orienta você através do desenvolvimento orientado a testes onde os testes definem o comportamento antes da implementação, resultando em código mais limpo e refatoração confiável.

지원: Claude Codex Code(CC)
📊 71 적절함
1

스킬 ZIP 다운로드

2

Claude에서 업로드

설정 → 기능 → 스킬 → 스킬 업로드로 이동

3

토글을 켜고 사용 시작

테스트해 보기

"tdd" 사용 중입니다. Me ajude a construir uma funcionalidade para adicionar itens a um carrinho de compras

예상 결과:

Vou guiá-lo através de TDD para esta funcionalidade. Primeira pergunta: o que deve acontecer quando um usuário adiciona um item? Devemos suportar quantidade? Qual comportamento deve ser verificável?

"tdd" 사용 중입니다. Escreva testes para autenticação de usuário

예상 결과:

Para testes de autenticação, foque em interfaces públicas: login, logout, manipulação de sessão. Recomendo testes estilo integração ao invés de mockar lógica interna de autenticação. Quais serviços externos sua autenticação usa?

"tdd" 사용 중입니다. Meus testes quebram sempre que eu refatoro

예상 결과:

Seus testes provavelmente estão acoplados a detalhes de implementação. Bons testes verificam comportamento através de interfaces públicas. Vamos identificar quais testes quebram e o que eles estão testando.

보안 감사

안전
v1 • 4/19/2026

All 48 static findings are false positives. The skill contains educational TDD documentation with code examples. External command flags were triggered by ASCII workflow diagrams (RED→GREEN patterns). Cryptographic algorithm flags were triggered by testing patterns like jest.mock() and StripeClient(). No malicious code or prompt injection detected.

6
스캔된 파일
307
분석된 줄 수
0
발견 사항
1
총 감사 수
보안 문제를 찾지 못했습니다
감사자: claude

품질 점수

38
아키텍처
100
유지보수성
87
콘텐츠
30
커뮤니티
100
보안
91
사양 준수

만들 수 있는 것

Construindo novas funcionalidades com TDD

Quando começar uma nova funcionalidade, esta skill ajuda a escrever testes primeiro que definem o comportamento esperado, então orienta implementação mínima para passar esses testes.

Corrigindo bugs com testes falhando

Quando um bug é relatado, esta skill ajuda a escrever um teste falhando que reproduz o bug, então orienta a correção do código para fazer o teste passar.

Melhorando código legado através de refatoração

Antes de refatorar código legado, esta skill ajuda a escrever testes de integração que capturam o comportamento atual, garantindo que refatorações não quebrem funcionalidade existente.

이 프롬프트를 사용해 보세요

Nova funcionalidade com TDD
Preciso adicionar [feature] em [module]. Me ajude a usar TDD para construir isso. Comece perguntando quais comportamentos testar primeiro.
Correção de bug com TDD
Há um bug onde [description]. Me ajude a escrever um teste falhando que reproduz isso, então corrija.
Melhorar cobertura de testes
Quero melhores testes para [module]. Revise meus testes atuais e sugira melhorias seguindo princípios TDD.
Refatorar com confiança
Quero refatorar [module]. Me ajude a escrever testes que capturam o comportamento atual primeiro, então oriente minha refatoração.

모범 사례

  • Escreva um teste de cada vez e apenas código suficiente para passá-lo
  • Use apenas interfaces públicas; testes devem sobreviver refatorações internas
  • Prefera testes estilo integração que verificam comportamento observável ao invés de mockar partes internas

피하기

  • Escrever todos os testes primeiro e depois toda a implementação (fatiamento horizontal)
  • Mockar colaboradores internos ao invés de testar através de interfaces públicas
  • Escrever testes que verificam detalhes de implementação ao invés de comportamento

자주 묻는 질문

Quando devo escrever testes em TDD?
Escreva o teste antes de qualquer código de implementação. O teste define qual comportamento você quer antes de construí-lo.
Quantos testes devo escrever de uma vez?
Escreva um teste de cada vez. Isso mantém seus ciclos pequenos e focados em um comportamento de cada vez.
O que devo testar se não consigo testar tudo?
Foque em caminhos críticos e lógica complexa. Confirme com seu usuário quais comportamentos são mais importantes para sua aplicação.
Devo fazer mock das minhas próprias classes ou módulos?
Não. Apenas mock nos limites do sistema como APIs externas, bancos de dados e sistemas de arquivos. Seu próprio código deve ser testado através de interfaces reais.
Quando devo refatorar em TDD?
Apenas refatore quando todos os testes passarem (no estado verde). Nunca refatore enquanto os testes estão falhando.
Como sei se meu teste é bom?
Um bom teste quebra quando o comportamento quebra mas sobrevive refatorações internas. Se renomear uma função interna quebra seu teste, o teste estava testando implementação e não comportamento.

개발자 세부 정보

작성자

mattpocock

라이선스

MIT

참조

main

파일 구조