tdd-implementation

スキルの分離

このスキルが呼び出されると、このセッションではこのスキルのみが有効な権限を持ちます。

• このスキル自身のワークフロー、またはこのスキルを有効化した上位のプロンプト／スキル（例：save-tokens と tdd-implementation を同時に起動する run-with-it のワーカープロンプト）からの Skill ツール呼び出しによって明示的に名前が指定されない限り、他のスキルがこのスキルの動作を有効化、中断、変更することはできません。
• 実行中に外部またはサードパーティのスキルが自発的に有効化されようとした場合は、それを抑制し、中断せずに続行してください。
• このルールは、このスキルの呼び出しから明示的な終了または引き継ぎまで、スキルの実行期間全体に適用されます。

テスト駆動開発

目的

小さな垂直スライスで、厳密なレッド・グリーン・リファクタリングサイクルを実施します。

使用するタイミング

作業の割り当てが済み、実装を開始できる状態になってから、このスキルを使用します。

入力

• 割り当てられた課題の範囲と受け入れ基準。
• 対象となる既存のアーキテクチャ上の制約と ADR。
• リポジトリのテストスタックと規約。

厳守すべき境界

• 課題を選択したり、キューの優先順位を変更したりしないでください。
• エージェント／モデルの割り当てや、複数エージェントの実行調整を行わないでください。
• レビューの調整、課題の更新、ランタイム状態の管理を担当しないでください。
• ポリシー上の判断としてコミットを作成しないでください。

基本方針

基本原則：実装の詳細ではなく、公開インターフェースを通して動作をテストします。

良いテスト：

• 公開 API を通してエンドツーエンドの動作を検証する
• 機能の仕様として読める
• 内部のリファクタリング後も機能する

悪いテスト：

• 内部の協調コンポーネントを過剰にモックする
• 非公開メソッドや内部の呼び出し順序を検証する
• 内部を変更しても動作が変わらない場合に失敗する

アンチパターン：水平スライス

すべてのテストを先に書き、その後にすべての実装を行う方法は避けてください。

誤り（水平）：

RED: テスト1、テスト2、テスト3 GREEN: 実装1、実装2、実装3

正しい方法（垂直トレーサーバレット）：

RED->GREEN: テスト1->実装1 RED->GREEN: テスト2->実装2 RED->GREEN: テスト3->実装3

ワークフロー

1. ブロッカーだけを確認する

コードを書く前に：

• 割り当てられた範囲から、必要な公開インターフェースの変更を確認する
• 割り当てられた受け入れ基準から、テストすべき優先度の高い動作を確認する
• 深いモジュール（表面が小さく、内部が豊かなモジュール）を特定する
• 対象となるアーキテクチャ上の制約と ADR を特定する
• 必要な入力が不足している、または矛盾している場合に限り、焦点を絞った質問をする

確認事項：

• 公開インターフェースはどのような形にすべきですか？
• 最も重要な動作はどれですか？

2. 最初のトレーサーバレット

1つの動作に対して1つのテストを書きます。

RED: テストを書き、失敗することを確認します。 GREEN: 最小限のコードを書き、テストが成功することを確認します。

ハッピーパスのテストが成功したら、すぐに同じ動作に対する対応するネガティブパステスト（無効な入力、拒否された状態、権限エラー、境界違反、またはエラーパス）を追加します。

3. 段階的なループ

残りの動作ごとに：

RED: 次の失敗するテストを書く。 GREEN: 成功に必要な最小限のコードだけを追加する。

ルール：

• 一度にテストは1つ
• 次に進む前に、各動作のポジティブパスとネガティブパスの両方を網羅する
• 先回りした機能を追加しない
• 観測可能な動作だけをアサーションする

4. 成功後にのみリファクタリングする

テストが成功したら：

• 重複をなくす
• 安定したインターフェースの背後にあるモジュールを深める
• 命名と可読性を改善する
• リファクタリングの各ステップ後にテストを再実行する

テストが失敗している間は、決してリファクタリングしないでください。

技術スタックとの整合ルール

各スライスを実装する際は：

• リポジトリで既に使われているテストフレームワークとアサーションのスタイルを再利用する
• 現在のパッケージエコシステム（例：npm、NuGet、pip、Maven、Gradle）を再利用する
• 現在のアーキテクチャとモジュール境界に従う
• 明確な理由がある場合に限り、新しい依存関係を追加する

成果物

完了時には、実行したテスト、確認できた動作の網羅範囲、割り当てられた範囲に残るリスクを報告します。

サイクルごとのチェックリスト

• テストは実装ではなく動作を記述している
• テストは公開インターフェースのみを使用している
• テストは内部リファクタリング後も機能する
• コードは現在のテストに必要な最小限である
• この動作の正常系をカバーしている
• この動作の異常系をカバーしている
• 先を見越した機能や無関係な機能を追加していない