Agent-Skills.md

Agent Skills: Test-Driven Development

機能実装やバグ修正時に使用。RED-GREEN-REFACTORサイクルとTesting Trophy手法を強制。

UncategorizedID: TakumiOkayasu/dotfile-work/test-driven-development

Repository

TakumiOkayasu/dotfile-work
TakumiOkayasu

Install this agent skill to your local

pnpm dlx add-skill https://github.com/TakumiOkayasu/dotfile-work/tree/HEAD/claude/skills/test-driven-development

Skill Files

Browse the full folder contents for test-driven-development.

Download Skill

Loading file tree…

claude/skills/test-driven-development/SKILL.md

Skill Metadata

Name
test-driven-development
Description
機能実装やバグ修正時に使用。RED-GREEN-REFACTORサイクルとTesting Trophy手法を強制。

Test-Driven Development

鉄則

テストを先に書く。実装コードを書く前にユーザー確認。

RED-GREEN-REFACTOR

  1. RED: 失敗するテストを書く → ユーザー確認
  2. GREEN: 最小限の実装でテストを通す
  3. REFACTOR: テストを維持しながら改善

テストなしの実装 → コード削除。やり直し。

実践テクニック (t-wada流)

  • 小さなステップ: 1つずつテストを書く (複数同時禁止)
  • 仮実装: テストを通すためにベタ書き (return 42) でもOK
  • 三角測量: 2つ目のテストケースで一般化する
  • 明白な実装: 答えが分かる場合は直接実装してもOK

テストコード変更の制限

テストは仕様。勝手に変更禁止。

許可される例外: テスト追加/修正の依頼、明らかな構文エラー、仕様矛盾 (要確認)

Testing Trophy

優先順位: 統合テスト > ユニットテスト > E2E

コミットルール

  • RED: test: add failing test for [feature]
  • GREEN: feat: implement [feature] to pass test
  • REFACTOR: refactor: [description]
  • テストが通ったらすぐコミット (小さく頻繁に)

AI生成テストの罠

  • [ ] テストは要件に基づいているか? (AIの実装仮定ではないか)
  • [ ] 境界値・異常系・null/空文字列のケースは含まれているか?
  • [ ] expect(result).toBeDefined() だけで終わっていないか?
  • [ ] モックが本物の振る舞いと乖離していないか?

対策: テストを書く前にテストケースを言語化。AI生成テストは必ずレビュー。REDで本当に失敗するか確認。

禁止事項

  • テストを書かずに実装する
  • テストを実装に合わせる (逆)
  • テストデータ依存の条件分岐
  • 複数テストケースを1つのitに
  • 既存テストの無断変更・削除