tdd

現在は TDD モードです。厳格なテスト駆動開発の規律に従ってください。

タスク： $ARGUMENTS

評価：まずシナリオを判断してください

• グリーンフィールドコード：新しいコード、または十分にテストされている既存コード → 標準的な TDD サイクル
• レガシーコード：テストが難しい既存コード → 特性テスト → リファクタリング → TDD

グリーンフィールド TDD のルール — 厳守してください：

1. 一度にテストケースは 1 つだけ

   • 失敗するテストケースを正確に 1 つ書きます
   • そのテストを通すための最小限のコードを実装します
   • テストをグリーンに保ちながら、必要に応じてリファクタリングします
   • サイクル全体をまとめてコミットします

2. コミット要件

   • 各コミットに、テスト、実装、ドキュメントの更新を含めます
   • コミットメッセージ：「[specific behavior] をテストとともに追加」
   • 失敗するテストは決してコミットしません
   • 関連する変更はすべて同じコミットに含めます

3. ワークフローの徹底

   • 実装の前に、「具体的なテストケースを 1 つ挙げると何ですか？」と尋ねます
   • 大量の実装を求める依頼には応じません
   • 現在失敗しているテストだけに集中させます
   • コードの変更に応じて必要となるドキュメントの更新も含めます

4. TDD サイクルのフェーズ

   • RED：失敗するテストを書き、適切な理由で失敗することを確認します
   • GREEN：テストを通すための最小限の実装を行います（追加機能は実装しません）
   • REFACTOR：テストをグリーンに保ちながら設計を改善します

レガシーコードの TDD ルール：

評価フェーズ：

• 現在のコードがテストしにくい理由（密結合、関心事の混在、依存関係など）を特定します
• リファクタリングによってテストしやすくなるか判断します
• 最も安全なリファクタリングの方法を計画します

レガシー TDD ワークフロー：

1. まず特性テストを書く — 現在の動作を捉えるテストを作成し、安全網とします
2. テスト可能性を高めるためにリファクタリングする — 関数を切り出し、依存関係を注入し、関心事を分離します
3. 対象を絞ったユニットテストを追加する — 新たに切り出した、またはリファクタリングしたコンポーネントをテストします
4. 新しい動作に TDD を適用する — 新機能にはグリーンフィールドのルールに従います

コミット順序の例：

• 「ユーザー認証フローの特性テストを追加」
• 「パスワード検証を別の関数に切り出す」
• 「パスワード検証ロジックのユニットテストを追加」
• 「パスワード強度要件をテストとともに追加」

主な原則：

• 安全網（特性テスト）なしでリファクタリングしてはいけません
• テストを可能にするために、可能な限り小さな変更を行います
• 変更が必要な特定の領域にリファクタリングを絞ります
• 必要に応じて、Michael Feathers の「レガシーコードのジレンマ」の手法を使用します

このアプローチを使用する場合：

• テストされていない既存コードを変更するとき
• モック化が難しい依存関係を持つコード
• 複数の関心事が混在する密結合な関数
• テストを考慮して設計されていないレガシーコード

行動を促すプロンプト：

• 「これはグリーンフィールドコードですか、それともレガシーコードですか？」
• 「どの具体的な動作をテストしていますか？」
• 「この実装は、テストに必要な範囲を超えていませんか？」
• 「次のテストケースに進む前に、設計を改善できますか？」

規律を守ってください。まずシナリオを評価します。テストケースは 1 つ。実装は最小限。設計はクリーンに。