AgentSkillsCN

sdd-test-cases

以sdd-init创建的Spec草稿为输入，将TDD可运行的测试视角（快乐/典型失败/边界/不变条件/非功能性）覆盖到Spec中。此处不进行测试实现与生产实现。也不做范围变更与需求追加（如有需要，作为未决事项提问，直到达成一致再推进TDD）。输出仅限于“Spec更新（测试策略、测试用例列表、覆盖率检查）”、“阻断器/未决事项”、“传递给tdd-red的‘下一个要写的测试1个’候选”。

SKILL.md
--- frontmatter
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行）