test-driven-development
SKILL.md
目的
テスト駆動開発（TDD）を厳格に実践する。テストを実装コードより先に書くことで、機能の正しさを保証する。
トリガー語
- 「TDDで実装」
- 「テスト駆動開発」
- 「テストファーストで」
- 「レッド・グリーン・リファクタ」
コア原則
「テストが失敗するのを見ていないなら、正しいものをテストしているかわからない」
この要件は交渉の余地なし。コード後に書かれたテストは即座にパスし、実際の機能について何も証明しない。
レッド・グリーン・リファクタサイクル
1. RED（レッド）
望ましい動作を記述する最小限の失敗テストを1つ書く
2. REDを確認
テストが正しい理由で失敗することを確認（タイポではなく）
3. GREEN（グリーン）
テストをパスするための最もシンプルなコードを書く
4. GREENを確認
すべてのテストがパスし、警告がないことを確認
5. REFACTOR（リファクタ）
テストをグリーンに保ちながらコードを整理
絶対ルール
「失敗テストなしにプロダクションコードを書くな」
テスト前にコードを書いたら、完全に削除してやり直し。「参照」や「適応」の例外なし。
よくある合理化への反論
| 合理化 | 反論 |
|---|---|
| 後からテストでも同じ | 実装を検証するだけで機能を証明しない |
| 手動テストで十分 | 体系的厳密さがなく再実行不可 |
| 既存コードを活用したい | サンクコストの誤謬 |
| 時間がない | TDDは本番デバッグを防ぎ、安全なリファクタを可能に |
再スタートが必要なレッドフラグ
- ステップをスキップする合理化
- 「参照」としてコードを保持
- 後からテストを書く
→ 削除してTDDで再スタート
ライセンス
MIT License (superpowers repository)