# Test Driven Development

> テスト駆動開発（TDD）の厳格な実践スキル。テストを先に書き、実装を後に書く規律あるアプローチ。

- Skill: `haru-llc/test-driven-development` (Agent Skill)
- Install (CLI): `npx skillmds@latest add haru-llc/test-driven-development`
- Raw SKILL.md: https://api.skillmd.com/api/skills/haru-llc/test-driven-development/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: HaRu-LLC (https://skillmd.com/u/haru-llc)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/haru-llc/test-driven-development

---


## 目的

テスト駆動開発（TDD）を厳格に実践する。テストを実装コードより**先に**書くことで、機能の正しさを保証する。

---

## トリガー語

- 「TDDで実装」
- 「テスト駆動開発」
- 「テストファーストで」
- 「レッド・グリーン・リファクタ」

---

## コア原則

> **「テストが失敗するのを見ていないなら、正しいものをテストしているかわからない」**

この要件は交渉の余地なし。コード後に書かれたテストは即座にパスし、実際の機能について何も証明しない。

---

## レッド・グリーン・リファクタサイクル

### 1. RED（レッド）

望ましい動作を記述する最小限の失敗テストを1つ書く

### 2. REDを確認

テストが**正しい理由で**失敗することを確認（タイポではなく）

### 3. GREEN（グリーン）

テストをパスするための最もシンプルなコードを書く

### 4. GREENを確認

すべてのテストがパスし、警告がないことを確認

### 5. REFACTOR（リファクタ）

テストをグリーンに保ちながらコードを整理

---

## 絶対ルール

> **「失敗テストなしにプロダクションコードを書くな」**

テスト前にコードを書いたら、完全に削除してやり直し。「参照」や「適応」の例外なし。

---

## よくある合理化への反論

| 合理化 | 反論 |
|--------|------|
| 後からテストでも同じ | 実装を検証するだけで機能を証明しない |
| 手動テストで十分 | 体系的厳密さがなく再実行不可 |
| 既存コードを活用したい | サンクコストの誤謬 |
| 時間がない | TDDは本番デバッグを防ぎ、安全なリファクタを可能に |

---

## 再スタートが必要なレッドフラグ

- ステップをスキップする合理化
- 「参照」としてコードを保持
- 後からテストを書く

**→ 削除してTDDで再スタート**

---

## ライセンス

MIT License (superpowers repository)