TDD実装（t-wada / Kent Beck 流）

設計が確定した後、テストリスト → Red → Green → Refactor のサイクルで実装する手法。要件理解・設計・必須ゲート通過・セルフレビューはこのスキルの責務外（呼び出し元が回す）。

---

Phase 1: テストリスト

実装に入る前に、検証したい振る舞いを過不足なくリスト化する。

• 完了条件・受入基準を「テストとして書ける粒度」に分解
• 正常系・異常系・境界値を含める
• 優先順位: 「テスト容易性 × 重要度 × 不確実性」が高いものから着手
• 1項目 = 1テストに対応

実装中に気付いた観点は着手前に必ずリストへ追記する（書き忘れ防止）。

---

Phase 2: Red — 1 つだけテストを書く

リストから 1 項目選び、テストコードに翻訳する。

• Arrange-Act-Assert で構造化
• 意味のあるアサーションを必ず置く（常に真の検証は禁止）
• テストが失敗することを確認するまで次に進まない
• 「正しい理由で失敗している」ことを確認（コンパイルエラーや想定外の例外で落ちていないか）

複数テストを先にまとめて書かない。1テスト→Red→Green→Refactor で1サイクル。

---

Phase 3: Green — 本当に成功させる

テストを通すための最小限の実装だけを書く。美しさは Refactor まで保留。

厳禁:

• アサーションの削除や緩和
• test.skip / コメントアウトでの回避
• テスト側を書き換えて「とりあえず緑」にする

実装の 3 つのギア

ギア	いつ使うか	やり方
仮実装（Fake It）	一般解への自信が無いとき、最初の一歩	ハードコードで通す（例: return 42）
三角測量（Triangulation）	仮実装の後、一般化を強制したいとき	別ケースのテストを追加し、ハードコードでは通らないようにして一般解を引き出す
明白な実装（Obvious Implementation）	一般解への自信が高く、テストとの結びつきが明確	いきなり一般化された実装を書く

迷ったら 仮実装 → 三角測量 のルートで安全側に倒す。

---

Phase 4: Refactor — 緑のうちに改善する

テストが緑のまま、設計を改善する。

Refactor 判断

質問	Yes なら refactor
同じロジックが2箇所以上に出現	✅
名前が振る舞いを表していない	✅
関数が複数の責務を負っている	✅
マジック値が散らばっている	✅

すべて No ならやらない判断を明示して次のテストへ。

禁止:

• 今のテストでカバーされていない設計変更
• 将来必要かもしれない抽象化の先取り
• テストを赤にする変更（赤になったら直ちに戻す）

---

Phase 5: 繰り返し

テストリストが空になるまで Phase 2〜4 を繰り返す。各サイクル終了時、既存テストを含む全テストが緑であることを確認する。

---

既存変更・バグ修正時の追加ルール

• 変更前に既存テストが全て緑であることを確認（基準点の固定）
• バグ修正は再現テスト先行: バグを再現する失敗テストを先に書き、それが緑になることで修正の妥当性を示す
• 変更後にも既存テストが緑であることを確認
• 後方互換性が壊れる場合は実装を進める前に呼び出し元へ申告

---

LLM 特有の罠と対策

罠	対策
実装ファーストに傾く	Phase 2 の Red 観測まで実装ファイルを開かない
テストをまとめ書き	1サイクル1テスト。追加観点は次サイクルへ
Green を急いで誤魔化す	アサーション緩和・スキップ禁止。仮実装は OK だが三角測量で一般化
Refactor を飛ばす	判断チェックリストを通過（やらない判断も明示）
テストリスト軽視	追加観点は実装前に必ずリストへ

---

テストコードのガイドライン

• プロジェクトのテストフレームワーク・既存パターンに従う
• 単体テストと結合テストの粒度を分けて書く
• モックは外部サービス・認証・インフラ層に限定（ビジネスロジックはモックしない）
• 1テスト1検証、テスト名は振る舞いの説明

---

完了条件

• テストリストの全項目がテストとして実装され、すべて緑
• 既存テストを壊していない
• 完了条件・受入基準をテストレベルで満たしている

/quality-check はこのスキルの範囲外（呼び出し元が完了後に実行）。

---

返却内容

• テストリスト（最終版・チェック状況）
• 追加・変更したファイル一覧（テスト / プロダクション別）
• 各サイクルで使ったギア（仮実装/三角測量/明白な実装）と理由
• 既存テストの実行状況（変更前/変更後）
• 後方互換性に影響がある場合はその内容