@see2et/sdd-test-cases

---
name: sdd-test-cases
description: sdd-initで作成したSpecドラフトを入力として、TDDを回せるだけのテスト観点（ハッピー/代表的失敗/境界/不変条件/非機能）をSpecに網羅する。ここではテスト実装・プロダクション実装は行わない。スコープ変更・要件追加もしない（必要なら未決事項として質問を起票し、合意が取れるまでTDDへ進ませない）。出力は「Specの更新（テスト戦略・テストケース一覧・カバレッジチェック）」「ブロッカー/未決事項」「tdd-redに渡す“次に書くべきテスト1つ”候補」に限定する。
---

# 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行）