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