sdd-test-cases（Specにテスト観点を網羅する）

目的

• Specを「契約」として強化し、以後のTDD（RED→GREEN→REFACTOR）で迷わない“実行可能な例”の母集団を作る。
• 仕様の曖昧さ・抜け漏れ・矛盾を、実装前に露出させる。
• ただし、詳細設計の深掘りや実装判断はしない（不明点は未決事項としてユーザーに返す）。

このスキルの責務 / 非責務（強制）

やること

• docs/specs/YYYYMMDD-*.md（対象Spec）を更新し、以下を追記/整備する：
  1. テスト戦略（どの層で何を担保するか）
  2. テストケース一覧（ID付き、観測可能な期待結果）
  3. カバレッジ確認チェックリスト（抜けを検知するための観点）
• 各テストケースを「要求（FR/NFR）」に紐づけ、トレーサビリティを作る。
• 曖昧さ・矛盾・未決事項を“問い”の形にして明確化する（ブロッカー判定を含む）。

やらないこと

• テストコードの実装、プロダクションコードの実装。
• 要件追加・スコープ拡張（必要なら「別スライス」または「未決事項」として返す）。
• 大規模な章立て変更（テンプレの枠を崩さない。追記セクションで対応する）。

前提（満たさない場合は停止）

• 対象Specが存在し、少なくとも以下が書かれている：
  • Goal / スコープ / 非スコープ
  • 機能要件（FR）と非機能要件（NFR）が最低限
• 上記が不足している場合：このスキルでは補える範囲で補い、不足がTDDの判断に直結するならブロッカーとして質問を起票する（解消までTDDへ進ませない）。

テスト戦略（標準方針）

• テストピラミッドを基本とする：Unitを厚く、Integrationを境界に、E2Eは最小限。
• デフォルトの割当：
  • Unit：ドメインロジック、入力検証、状態遷移、不変条件（invariants）
  • Integration：DB/外部API/ファイルI/O/メッセージング等の境界、設定/DI、シリアライズ
  • E2E：最重要ユーザーフローを1〜数本（“動く証拠”として）
• 不安定化の芽を潰す：
  • 時刻・乱数・並行性・外部依存はテスト容易性のために制御可能にする（Clock/Random/Executor 等の注入を検討。ただしこのスキルでは実装しない）。

作業手順（厳守）

1. 対象Specの特定

   • 入力（会話）でSpecパスが示されていればそれを使う。
   • 不明なら docs/specs/ を検索し、候補を提示して最も適切な1つを選ぶ（このスキル内で確定）。

2. 要件IDの整合

   • FR/NFRにIDが付いていない、または粒度が粗すぎる場合：
     • 破壊的に細分化しない範囲で、最小限のID付与/分割を行う（例：FR-001〜）。
   • 以後のテストケースは必ず FR/NFR のいずれかに紐づく。

3. テストケース設計（“網羅”の定義） 各FR/NFRごとに、最低限以下を揃える（詳細はプロダクト特性に応じて増減）：

   • Happy path：1つ以上（既にある場合は流用・改善）
   • Representative failure：1つ以上（代表的な失敗）
   • Boundary cases：2〜5個（境界値・空・最大長・最小長・桁あふれ等、仕様に依存）
   • State transition：状態があるなら遷移前/遷移後の観測
   • Invariants：常に成り立つべき性質（例：整合性、単調性、idempotency 等）
   • Observability：期待結果は“観測可能な振る舞い”で書く（戻り値/エラーコード/メッセージ/永続化状態/ログなど）

4. テストケースを「層」に割り当てる

   • 可能な限り Unit に寄せる（速く・壊れにくく・リファクタ耐性）。
   • 統合が本質のケースだけ Integration/E2E に上げる（むやみにE2Eで代替しない）。
   • 依存をテストダブルにする場合は“境界”で行い、内部実装の呼び出し回数や順序への過度な依存は避ける。

5. カバレッジ確認チェックリストを埋める

   • 抜けやすい観点を列挙し、該当/非該当を明示する（曖昧なら未決事項へ）。
   • 例：入力検証、権限、互換性、並行実行、再試行/リトライ、タイムアウト、監査ログ、ロールバック、移行、性能上限 など。

6. 未決事項（Open Questions）の更新

   • テストケースが書けない原因を“問い”に落とす。
   • その問いが「TDDの次の一歩（RED）を止めるか」を判定し、ブロッカーを明示する。

7. tdd-redへの引き渡し

   • 作成したテストケース一覧から、次に着手すべき テスト1つ（TC-xxx）を推奨する。
   • 推奨理由は、学習価値（不確実性解消）/リスク/価値のいずれかで説明する。

Specに追記するセクション（テンプレ）

対象Specに以下を追記する（既に似た章があれば統合して良いが、情報は落とさない）：

テスト戦略

• テスト層の方針（Unit/Integration/E2E）
• 依存（DB/API/Clock等）の扱い方針（安定性・再現性）

テストケース一覧

// 推奨フォーマット

TC-ID：TC-001

• 対応要件：FR-001 / NFR-001
• 種別：Happy / Failure / Boundary / Invariant / Non-functional
• テスト層：Unit / Integration / E2E
• Given：前提（状態・入力・依存）
• When：操作
• Then：期待結果（観測可能に）
• メモ：テストデータ、注意点、既存の類似テスト参照（あれば）

ストップ条件（ここで止まり、ユーザーへ質問）

• FR/NFRの観測可能な期待結果が定義できず、テストケースが“推測”になる。
• 重大な制約（互換性/セキュリティ/運用）不明で、テスト観点が確定できない。
• 同じ要件に対し、Spec内で矛盾する記述がある。

出力フォーマット（このスキルの返答）

1. 更新したSpec: docs/specs/YYYYMMDD-*.md
2. 追加/更新した要件ID:（FR/NFRの一覧。増やしすぎない）
3. 追加したテストケース数:（TC数と内訳：Happy/Failure/Boundary/Invariant/NFR）
4. ブロッカー（未決事項）:（あれば）
5. 次にやるRED（推奨TC）: TC-xxx（理由1行）