Test-Driven Development

トリガー条件

以下のすべてに該当する場合に発動する:

発動しない場合（除外条件）:

前提条件

本スキルを開始する前に以下が満たされていること:

• プロジェクトにテストランナーが存在する（なければユーザーに確認）
• テスト実行コマンドが判明している
• 作業ブランチが作成済み（mainブランチ直接作業は禁止）

鉄則（すべてに優先）

1. REDを確認するまで実装コードを書かない。 テスト実行→FAIL確認→実装の順序を守る。
2. テストは仕様。 テストの期待する振る舞いをユーザー確認なしに変えない。

この2つに違反した場合: 実装コードを削除し、テストのRED確認からやり直す。

なぜ重要か: テストを先に書く理由は「正しい問いを立ててから答える」ため。RED確認のスキップは「答えに合う問いを後付けする」行為であり、テストの信頼性を根本から損なう。

ステップ0: プロジェクト検出（最初に必ず実行）

テストコードを書く前に、以下を順番に検出する:

1. テストフレームワーク（Jest / Vitest / pytest / JUnit / RSpec / Go testing / Rust #[test] 等）
2. テストファイルの配置規約（__tests__/、*.test.ts、*_test.go、tests/ 等）
3. テストの命名規約（既存テストから推測）
4. テスト実行コマンド（npm test、pytest、go test ./...、cargo test 等）
5. 関連スキルの有無（git-workflow、refactoring、code-review 等）

1つでも検出できなければユーザーに確認する。推測で補わない。

ステップ1: 適用判断

テストの書き方はコードの状態に依存する。以下のシグナルで判断し、迷ったらユーザーに確認する。

仕様の確度を判断するシグナル

テスタビリティを判断するシグナル

判断結果→行動

「探索的」は常にユーザー申告制。AIが勝手に判断して実装先行しない。

ステップ2: テストリスト作成

テストコードを書く前に、テストケースを自然言語でリストアップする。

// テストリスト例: ポイント計算機能
// □ 1000円の購入で10ポイント付与される
// □ 999円の購入ではポイント0
// □ 負の金額ではエラー
// □ ゴールド会員は2倍のポイント
// □ 0円の購入ではポイント0（境界値）

順序の決め方

1. そのテストを通すために核となるインターフェースや型の決定が必要 → 優先度高
2. 既存の実装に変更なく通せる → 優先度低
3. 判断がつかない → 最も単純なケースから

テストリストは完璧でなくてよい。サイクル中に気づいたケースはリストに追加し、現在のサイクル完了後に着手する。

✅ リスト作成後、ユーザーに網羅性と優先順位を確認する。

「以下のテストケースで進めます。追加・変更・優先順位の調整はありますか?」

ステップ3: RED-GREEN-REFACTORサイクル

RED: 失敗するテストを書く

手順（この順序を守ること）:

1. テストケースを自然言語で言語化する（「何をテストするか」を明文化）
2. テストコードを書く（1サイクルにつき1テストケースのみ）
3. テストを実行する
4. 意図した理由でFAILすることを出力で確認する（スキップ禁止）

確認ポイント:

• コンパイルエラーや設定ミスではなく、機能が未実装だからFAILしているか?
• テスト名から「対象」「条件」「期待結果」が読み取れるか?

❌ FAILを確認できない場合は実装に進まない。テストを見直すかユーザーに報告する。

GREEN: 最小限の実装でテストを通す

3つのテクニックを状況に応じて使い分ける:

GREENではテストを通す最小限の変更だけ行う。「ついでに」のリファクタリングはしない。

REFACTOR: テストを維持しながら改善

GREENの直後に毎回判断する。以下のいずれかに該当すれば実施:

• 直前のGREENで明らかな重複が生まれた
• 命名が意図を反映していない
• 1つの関数/メソッドが複数の責務を持っている

該当しなければスキップしてよい。REFACTORは義務ではなく機会。

やること: 重複除去、命名改善、責務分離。全テストがGREENのまま。
やらないこと: 新機能追加（REDに戻る）、テストの振る舞い変更。

ステップ4: 特性テスト（レガシーコード対応）

テストがない/信頼できないコードに対する段階的導入。

フェーズ1: 現状を記録する

現在の振る舞いを「そのまま記録する」テストを書く。正しいかどうかは問わない。

分離方法はプロジェクトの慣習に合わせる。慣習がなければ以下から選択:

• describe("CHARACTERIZATION: ...") / @Tag("characterization") / テスト名に [characterization] プレフィックス / ファイル名で分離

期待値に確信がない場合は // TODO: 仕様確認後に修正 コメントを付ける。

フェーズ2: 変更箇所にTDDを適用

1. 変更対象の周辺に特性テストを書く（安全網）
2. 新しい振る舞いのテストをRED-GREEN-REFACTORで追加
3. 仕様が確認できた特性テストを通常テストに昇格

フェーズ3: 触った箇所から拡大

変更のたびにテストを充実させる。特性テストが減り、TDDテストが増える状態を目指す。

テストコード変更のルール

変更してよい場合

• テストケースの追加
• テストの構文エラー修正（意図を変えない範囲）
• ユーザーからの仕様変更指示に伴う期待値の変更
• テストヘルパー抽出など、振る舞いを変えないリファクタリング
• インターフェース変更に伴う呼び出し方の更新（期待する振る舞い自体は不変）

禁止

• 振る舞いが変わっていないのにアサーションの期待値を変える
• FAILするテストを削除して緑にする
• アサーションを緩くしてPASSさせる（== 10 → != null 等）
• ユーザー確認なしでテストの期待する振る舞いを変更する

判断基準: 「テスト対象の公開インターフェースから見て、振る舞いは変わったか?」 変わっていなければ期待値は変えない。

出力形式テンプレート

テストリスト提示時

## テストリスト: [機能名]

□ [正常系1]: [入力] → [期待結果]
□ [正常系2]: [入力] → [期待結果]
□ [境界値]: [入力] → [期待結果]
□ [異常系1]: [入力] → [期待結果（例外/エラー）]

追加・変更・優先順位の調整はありますか?

RED確認報告時

## RED確認 ✅

テスト: [テスト名]
実行結果: FAIL
失敗理由: [実装が未存在 / 期待値 X に対し実際は Y]

→ 実装に進みます。

GREEN完了報告時

## GREEN完了 ✅

テスト: [テスト名]
実行結果: PASS
実装内容: [1〜2行で説明]

→ REFACTORを判断します。[実施する/スキップ（理由）]

サイクル完了報告時

## サイクル完了

完了: [N]件 PASS / 残り: [M]件
次のテストケース: [ケース名]

続行しますか?

AI固有の注意点

RED確認のスキップが最も危険。 テストが最初からPASSする場合、そのテストは何も検証していない可能性がある。「意図した理由でFAILする」ことの確認が品質の要。

ユーザー確認ポイント

すべてのステップで確認を求めると開発リズムが崩れる。以下のタイミングで確認する:

方向性が確定した後の反復的なRED-GREEN-REFACTORは、まとめて進めてよい。

コミット戦略

全テストがPASSした状態でのみコミットする。コミットメッセージはプロジェクト慣習に従う（git-workflowスキルがあれば参照）。

RED（FAILするテスト）単独ではコミットしない。RED+GREENをセットでコミットする。

関連スキルとの連携

禁止事項