incremental-tdd

テスト駆動開発（Red-Green-Refactor）

このスキルでは、短いTDDサイクルで作業します。失敗するテストを1つ書き、実装を1つ行い、その後にリファクタリングします。垂直スライスと深いモジュールを優先することで、テストが実装の詳細ではなく、実際の振る舞いを対象とした、信頼できて安定したものになるようにします。

このスキルには、考え方や例を参照できる追加ドキュメントが付属しています。

• deep-modules.md – 深いモジュールによってAI主導のTDDがより簡単かつ安全になる理由。
• refactoring.md – 安全なリファクタリングのパターン。
• interface-design.md – TDD向けのインターフェース設計方法。
• mocking.md – 自分をごまかさずにモックを使う方法とタイミング。
• tests.md – 自分をごまかさずにモックを使う方法とタイミング。

設計やリファクタリングの指針が必要な場合は、推測せずに、これらのファイルを開いて読んでください。

使用するタイミング

ユーザーが次のことを求めている場合に、このスキルを使用してください。

• TDDを使って機能を開発したり、バグを修正したりする。
• 「red-green-refactor」「テストファースト」「まずテストを書く」といった言葉に言及する。
• 壊れやすいユニットテストではなく、設計を導く、信頼できる統合テストやモジュールレベルテストを求めている。
• 長時間の「Ralph」ループや自律型エージェントを実行しており、変更の品質を高めたい。

要件が明確でない場合は、まず /grill-me と /spec-writer を使うよう提案し、その後、実行のためにここへ戻ってください。

全体的なワークフロー

状況が明らかな場合は手順を簡略化できますが、red → green → refactorの原則は守ってください。

1. 振る舞いとインターフェースを明確にする

   • 外部から見て、どのような振る舞いが必要かを確認します。重要な入力、出力、観察可能な効果を特定します。
   • その振る舞いを公開するために使う、または設計するインターフェース（公開関数、ハンドラー、エンドポイントなど）を特定します。
   • 深いモジュールを優先します。数を絞った大きなモジュールの上に、薄く安定したインターフェースを設けます。
   • 必要に応じて deep-modules.md を開き、その考え方に合わせてインターフェース設計を調整します。

2. 次の垂直スライスを選ぶ

   • PRDや問題の説明をもとに、システム内の実際の経路を通る1つの振る舞いを、小さな垂直スライスとして選びます。
   • 「DBテーブルをセットアップする」「UIをすべて作る」など、単独で完結する水平スライスは避けます。
   • このスライスの完了時に何を証明するのか、ユーザー（またはコメント）と確認します。

3. Red：失敗するテストを1つ書く

   • 選んだインターフェースを使い、スライスで実現したい振る舞いを表すテストを1つ書きます。
   • モジュールレベルのテストであっても、実際の呼び出し元が使う方法にできるだけ近づけます。
   • 大掛かりなモックよりも、実際の協調オブジェクトや薄いフェイクを優先します。迷った場合は mocking.md を参照してください。
   • テストを実行し、想定した理由で失敗することを確認します。

4. Green：最小限の実装を書く

   • 関連する本番コードのファイルを開き、テストを通すための最もシンプルな実装を書きます。
   • 過度に汎用化したり、使われないパラメーターを追加したり、まだテストされていない将来の振る舞いを実装したりしないでください。
   • テストを再実行し、新しいテストが通り、テストスイート全体も成功することを確認します。

5. Refactor：設計を安全に改善する

   • テストがすべて成功した状態で、重複、扱いにくいインターフェース、漏れのある抽象化がないか確認します。
   • 振る舞いが変わらないことを確認できるよう、頻繁にテストを実行しながら小さなリファクタリングを行います。
   • 境界を適切にし、より深いモジュールを設計するための指針として、deep-modules.md と refactoring.md を使います。
   • その時点で設計が「十分に良い」状態になったら終了します。今後のスライスを進めた後に、またリファクタリングできます。

6. サイクルを繰り返す

   • 次のスライスまたは振る舞いを選び、Red → Green → Refactorを繰り返します。
   • 各サイクルは、問題が起きたときに内容を理解して元に戻せる程度に、小さく保ちます。
   • 作業を進める中で、テストは振る舞いに集中させ、偶発的な実装の詳細に結び付けないようにします。

振る舞いとルール

1. 常にループを守ってください。 失敗するテストを書く前に、本番コードを大量に書いてはいけません。
2. テストは一度に1つずつ。 一度に何十個ものテストを生成しないでください。振る舞いに応じて、段階的にテストを追加してください。
3. より高いレベルのテストを優先してください。 適切な場合は、実際のフローを検証する統合テストやモジュールレベルのテストを優先してください。
4. 誤解を招くテストを防いでください。 実際の振る舞いが壊れていても通ってしまうようなテストは避け、明らかな誤検知がないか確認してください。
5. 自分のコードを変更することをためらわないでください。 より良い設計が見つかった場合、以前に書いたコードは破棄可能なものとして扱い、安全性はテストに委ねてください。
6. 添付ドキュメントを使用してください。 モジュールの構成、リファクタリング、モックについて確信が持てない場合は、パターンを想像で補わず、リンク先の Markdown ファイルを開いてください。

フローの例

ユーザー： 「TDD を使って、週次の管理者向けサマリーメールを実装してください。PRD と issue はすでにあります。」

あなた（概要）：

1. PRD と issue に目を通し、最初の垂直スライス（例：「単一チームの週次メトリクスを計算する」）を特定します。
2. メトリクスの計算を担当するモジュールのインターフェースを設計または確認し、ガイダンスとして deep-modules.md を参照します。
3. 「先週のイベントをもとに、チーム X のサマリーオブジェクトを計算する」という単一の失敗するテストを書きます。
4. そのテストを通すために必要最小限のコードを実装し、テストが成功し続ける状態を保ちながらモジュールをリファクタリングします。
5. 追加の振る舞い（複数チーム、フィルター、パフォーマンス要件、エラー処理）についても、常にレッド・グリーン・リファクタリングのサイクルで繰り返します。