技能 test-driven-development
📦

test-driven-development

安全

테스트 주도 개발 적용하기

也可從以下取得: CodingCossack,Cygnusfear,Cycleaddict,obra,davila7,DMJGilbert,DYAI2025,sickn33

코드 작성 후에 테스트를 작성하면 잘못된 신뢰와 놓친 엣지 케이스로 이어집니다. 이 스킬은 TDD 규율을 강제합니다: 먼저 실패하는 테스트를 작성한 다음, 이를 통과하기 위한 최소한의 코드만 구현합니다.

支援: Claude Codex Code(CC)
🥉 72 青銅
1

下載技能 ZIP

2

在 Claude 中上傳

前往 設定 → 功能 → 技能 → 上傳技能

3

開啟並開始使用

測試它

正在使用「test-driven-development」。 이메일 주소 유효성 검사 함수를 추가해야 합니다

預期結果:

TDD 로 시작하겠습니다. 먼저 실패하는 테스트를 작성합니다:

```typescript
test('rejects invalid email', () => {
expect(validateEmail('invalid')).toBe(false);
});
```

이제 이 테스트를 실행하여 실패하는 것을 확인하겠습니다...

正在使用「test-driven-development」。 login 함수는 잘못된 비밀번호를 처리해야 합니다

預期結果:

TDD 에 따라 먼저 테스트:

```typescript
test('rejects wrong password', async () => {
const result = await login('user@test.com', 'wrongpass');
expect(result.success).toBe(false);
expect(result.error).toBe('Invalid credentials');
});
```

테스트 실행하여 실패하는 것 확인 중...

安全審計

安全
v1 • 2/24/2026

This is a legitimate Test-Driven Development educational skill. The static analyzer detected 73 potential issues, but after semantic evaluation, all findings are FALSE POSITIVES. The 'external_commands' detections are markdown code block delimiters (backticks) in documentation, not actual shell execution. The 'weak cryptographic algorithm' and 'network reconnaissance' detections are similarly false positives triggered by keywords in educational context. No executable malicious code exists in this skill.

2
已掃描檔案
672
分析行數
1
發現項
1
審計總數
中風險問題 (1)
Markdown Code Block Delimiters Flagged as Shell Execution
The static scanner detected 'Ruby/shell backtick execution' patterns in markdown files. These are FALSE POSITIVES - the backticks are markdown code fence delimiters (```typescript, ```bash) used for syntax highlighting in documentation, not runtime command execution. The skill is educational content about TDD methodology with no actual shell commands being executed.
審計者: claude

品質評分

38
架構
100
可維護性
87
內容
40
社群
100
安全
91
規範符合性

你能建構什麼

새 기능 구현

새 기능을 구축할 때, 예상 동작을 정의하는 테스트를 먼저 작성하고 실패하는 것을 확인한 다음, 통과하도록 구현합니다

버그 수정 워크플로

버그를 수정할 때, 먼저 버그를 재현하는 테스트를 작성하고 실패하는 것을 확인한 다음, 코드를 수정하여 통과시킵니다

신뢰를 가진 리팩토링

리팩토링 전에 테스트가 있는지 확인합니다. 테스트는 코드 변경 후에도 동작이 올바르게 유지되는지 검증합니다

試試這些提示

새 기능에 대한 TDD 시작 
[기능 설명] 을 구현해야 합니다. TDD 에 따라 먼저 예상 동작을 정의하는 실패하는 테스트를 작성하세요. 아직 구현 코드는 작성하지 마세요.
Red 단계 검증 
방금 작성한 테스트를 실행하고 올바른 이유로 실패하는지 확인하세요 (기능 누락으로 인한 것이지 오타 때문이 아님). 정확한 실패 메시지를 보여주세요.
Green 단계 - 최소 구현 
이제 테스트를 통과하기 위한 최소한의 코드를 작성하세요. 추가 기능을 추가하거나 리팩토링하지 마세요. 테스트만 통과시키세요.
버그 수정을 위한 TDD 
[버그 설명] 라는 버그가 있습니다. 먼저 이 버그를 재현하여 실패하는 테스트를 작성하세요. 그 다음 수정하겠습니다.

最佳實務

  • 한 번에 하나의 테스트 작성 - 단일 동작에 집중
  • 테스트 이름을 검증하는 동작으로 명명, 테스트 대상이 아닌 것으로
  • 구현 작성 전에 항상 테스트가 실패하는지 확인
  • 구현은 최소한으로 - 현재 테스트만 통과

避免

  • 테스트 전에 구현 코드 작성 (그 후 테스트를 '조정')
  • 테스트 작성 중 '참고용'으로 실패한 구현 코드 유지
  • 즉시 통과하는 테스트 - 아무것도 증명하지 않음
  • 실제 컴포넌트 동작 대신 모크 동작 테스트

常見問題

테스트 주도 개발이란 무엇입니까?
TDD 는 실패하는 테스트를 먼저 작성한 다음, 이를 통과하기 위한 최소한의 코드를 작성하고, 그 후 리팩토링하는 방법론입니다. 사이클은: Red (실패), Green (통과), Refactor 입니다.
왜 코드 전에 테스트를 작성합니까?
코드 작성 후 테스트는 즉시 통과하므로 아무것도 증명하지 않습니다. 먼저 테스트를 작성하면 원하는 동작을 정의하고 테스트가 실제로 버그를 감지하는지 증명하게 됩니다.
테스트 작성이 어렵다면 어떻게 합니까?
테스트 작성이 어렵다는 것은 설계가 너무 복잡하다는 것을 나타냅니다. 인터페이스를 단순화하거나 의존성 주입을 사용하여 코드를 테스트 가능하게 만드세요.
간단한 코드는 TDD 를 건너뛸 수 있습니까?
아닙니다. 간단한 코드도 깨집니다. 테스트 작성 시간은 최소화되며, 코드가 작동함을 증명하고 향후 회귀를 방지합니다.
이미 구현 코드를 작성했다면 어떻게 합니까?
삭제하세요. TDD 로 다시 시작하세요. 기존 코드를 유지한 후 테스트를 추가하는 것은 목적을 무너뜨리고 잘못된 신뢰를 줍니다.
TDD 가 개발을 느리게 합니까?
아닙니다. TDD 는 커밋 전에 버그를 발견하고 회귀를 방지하며 안전한 리팩토링을 가능하게 합니다. 사후 디버깅은 TDD 보다 느립니다.

開發者詳情

作者

ZhanlinCui

授權

MIT

儲存庫

https://github.com/ZhanlinCui/Ultimate-Agent-Skills-Collection/tree/main/test-driven-development

引用

main

檔案結構

📄 SKILL.md

📄 testing-anti-patterns.md