| name | test-design |
| description | 振る舞いを実装・テストコードを書く**前**に、何をテストすべきかを体系的に導出し「テストケース設計表」(ケース一覧 + 各ケースの導出根拠) として出力する設計スキル。対象の事前条件・事後条件・不変条件を明文化したうえで、入力の形 (範囲を持つ / 条件の組合せ / 状態を持つ / 可逆変換や代数的性質を持つ / 参照実装がある 等) に応じて同値分割・境界値分析 (BVA)・デシジョンテーブル・状態遷移テスト・ペアワイズ/組合せテストと、property-based の invariant / roundtrip / oracle / metamorphic / idempotence を選び分け、Google Software Engineering の Test Sizes (Small/Medium/Large) でどのケースをどのレイヤに置くかまで決める。「テストケース考えて」「どんなテスト書けばいい?」「テスト設計して」「テスト観点洗い出して」「境界値どこ?」「property 何にする?」「この関数の事前条件・事後条件は?」「実装する前にテストケース洗い出したい」のような要請、いずれでも必ず起動すること。既存テストのレビューは `test-review`、RED-GREEN の実行サイクルは `tdd`（本スキルは `tdd` Step 1 の前段として設計表を渡す関係）、テスト diff の検出力監査は `test-mutation-gate` の担当で、いずれも本スキルの範囲外。本スキルは書く前の設計表を出すところまでで、テストコード自体は書かない。 |
Test Design
テストを書くコストは「何をテストすべきか決めるコスト」と「それをコードに落とすコスト」に分解できる。後者は tdd の RED ステップが担うが、前者を場当たりで済ませると、目についたケースだけを書いて体系的な抜け（境界の片側だけ、条件組合せの一部だけ）が残る。本スキルは前者だけを担当し、確立されたテストケース設計技法で入力から導出可能なケースを漏れなく列挙してから tdd に渡す。
出力は常に「テストケース設計表」1 本。技法の解説や一般論を長々書かない。
いつ使うか / 使わない場面
発火すべき状況（口語含む）:
- 「テストケース考えて」「どんなテスト書けばいい?」「テスト設計して」
- 「テスト観点洗い出して」「境界値どこ?」「property 何にする?」
- 「この関数の事前条件・事後条件は?」「不変条件は何?」
- 「実装する前にテストケース洗い出したい」「仕様からテスト導出して」
tdd Step 1 (RED) に入る前、書くべきテストの一覧が定まっていないとき
発火しない場面 → 該当 skill 名を明示する:
- 既に書かれたテストコードの品質・smell・seam を見る →
test-review
- 設計表の 1 行を実際に RED テストとして書き、実装して GREEN にする →
tdd
- 書かれたテストが実装のミューテーションを検出できるかを監査する（boundary-gap warn の解消） →
test-mutation-gate
- テストを直す・追加する・カバレッジを機械的に上げる（分析ではなく実装作業） →
tdd または直接編集
- API 仕様そのものを決める（本スキルは既に確定した仕様/契約からケースを導出するだけ） →
design / software-design
ワークフロー
Step 1 — 対象の仕様・契約を明文化する
対象関数 / API / モジュールについて、次を書き出す。曖昧なまま Step 2 に進まない — 契約が言葉にできないものは、テストケースも言葉にできない。
- シグネチャ: 入力パラメータの型・範囲・多重度
- 事前条件 (precondition)
P: 呼び出し側が満たすべき前提
- 事後条件 (postcondition)
Q: 呼び出し後に保証される性質
- 不変条件 (invariant): 呼び出し前後で常に成り立つ性質
{P} C {Q} の形（Hoare 論理）で 1 行にまとめられるかを確認する。詳細な導出手順は references/contracts-and-properties.md。
契約が仕様書やコードコメントから読み取れない場合、黙って推測せず AskUserQuestion で確認する（曖昧な前提でケースを作ると、導出根拠が書けない）。AskUserQuestion が使えない場合（非対話実行・subagent 文脈）は、採用した仮定と却下した代替解釈を契約に明示した上で Step 2 に進んでよい。
契約に含める項目は与えられた仕様文からトレース可能なものに限る。トレースできない前提からはテスト行を作らず「未決の契約質問」に回す。仕様が部分的な場合（例: あるエラーケースだけ明記され、他の異常系の挙動が未記載）は、仮定した契約項目に「要確認」タグを付け、設計表とは別枠で「未決の契約質問」セクションに出力する（フォーマットは Step 5 参照）。
両者の境界は次の例で見分ける。完全にトレース不能（仕様が全く触れていない挙動、例: 未記載の状態遷移）は設計表に行を作らず「未決の契約質問」のみに書く。部分的に仮定を置いた場合（仕様の記述から合理的に補間した、例: エラーになることは明記されているが例外型が未記載）は「要確認」タグ付きで設計表に行を残しつつ、同じ論点を「未決の契約質問」にも書く。
Step 2 — 技法を選ぶ（決定表）
対象の入力の形で技法を選ぶ。1 つの対象に複数技法が同時に該当してよい（例: 数値レンジの各水準にデシジョンテーブルの条件を掛け合わせる）。
| 入力の形 | 技法 | 参照 |
|---|
| 範囲・長さ・順序を持つ入力（数値レンジ、文字列長、配列長など） | 境界値分析 (BVA) | references/classical-techniques.md §2 |
| 独立した入力次元ごとに有効/無効のクラスがある | 同値分割 | references/classical-techniques.md §1 |
| 複数条件の組合せで分岐が決まる | デシジョンテーブル | references/classical-techniques.md §3 |
| 呼び出しの結果が内部状態・ライフサイクルに依存する | 状態遷移テスト | references/classical-techniques.md §4 |
| パラメータ数が多く全組合せが非現実的 | ペアワイズ/組合せテスト | references/classical-techniques.md §5 |
| 事前条件・事後条件・不変条件が明文化できる | 契約からの導出 (Hoare 論理) | references/contracts-and-properties.md §1 |
| 可逆変換・代数的性質を持つ（encode/decode, ソート, 正規化, 冪等操作） | property-based (roundtrip / idempotence / metamorphic) | references/contracts-and-properties.md §2 |
| 素朴な参照実装・別実装が既にある | property-based (oracle) | references/contracts-and-properties.md §2 |
安全性が重要でリスクが高い領域（決済・認可・破壊的操作など）では、ペアワイズの間引きを使わず全組合せを優先する。判断基準は「組合せ漏れの発見コスト vs. テスト本数」— 曖昧なまま間引かず、明示的にどちらを選んだか設計表の導出根拠列に書く。
Step 3 — ケースを列挙する
Step 2 で選んだ技法ごとに、該当 reference の手順に従ってケースを機械的に列挙する。手作業で「思いつくケース」を足さない — 技法が要求するケース（境界の on/off 両点、デシジョンテーブルの全列、状態遷移の 0-switch/1-switch など）を漏れなく出し切ってから、技法がカバーしない着眼点があれば追加する。
Step 4 — サイズを配分する（Small/Medium/Large）
列挙した各ケースについて、実行に必要な境界（プロセス境界・ネットワーク・時間）を見て Test Size を割り当てる。判断基準の詳細は references/test-sizes.md。
- 純粋な入出力変換・契約検証だけなら Small に寄せる（外部 I/O なし、決定的、高速）
- DB / ファイルシステム / ローカルプロセス間通信が要るなら Medium
- 複数サービス・実ネットワーク・実クロックが要るなら Large、かつ本数を絞る
このとき change-detector test（実装の呼び出し順や内部手続きをそのまま写経したテスト）になっていないかを確認する — 設計表の「期待」列は常に観測可能な出力・状態でなければならず、内部実装の手順ではない。
Step 5 — 出力する
下記固定フォーマットのテストケース設計表を 1 本出力する。ケースは技法単位でグルーピングしてよいが、表自体は 1 本にまとめる。
出力フォーマット
# Test Design: <対象名>
## 契約
- Signature: <関数シグネチャ>
- Precondition (P): <箇条書き>
- Postcondition (Q): <箇条書き>
- Invariant: <箇条書き、無ければ「なし」>
## テストケース設計表
| # | 技法 | 入力 | 期待 | 導出根拠 (契約/境界/property) | サイズ |
|---|---|---|---|---|---|
| 1 | BVA | <境界の on/off 値> | <観測可能な出力> | 境界: <どの境界の何点目か> | Small |
| 2 | 契約 | <事前条件違反の入力> | <エラー系の観測可能な振る舞い> | precondition 違反: <どの条件か> | Small |
| 3 | property/roundtrip | <ランダム化された入力の生成規則> | `decode(encode(x)) == x` | roundtrip 性質 | Small |
| 4 | BVA/デシジョンテーブル | <境界値かつ条件組合せに該当する入力> | <観測可能な出力> | 境界: <...> + 条件列: <...> | Small |
| ... | ... | ... | ... | ... | ... |
## Test Size 内訳
- Small: <件数> / Medium: <件数> / Large: <件数>
## 未決の契約質問（該当する場合のみ）
- <トレースできない、または仕様未記載で「要確認」タグを付けた契約項目とその理由>
## 次のアクション
- 各行は `tdd` Step 1 の RED テスト 1 本に対応する
「導出根拠」列は必ず埋める。「なんとなく思いついた」ケースは列挙しない — 技法かその技法が要求する着眼点（境界名、契約の条件名、property の種類）まで遡って書く。1 ケースに複数技法が該当する場合は行を複製せず、技法列に BVA/デシジョンテーブル のように / 区切りの複合ラベルで統合する（上表の 4 行目参照）。
このスキルがやらないこと
- テストコードの実装: 設計表の 1 行を実際の RED テストに落とすのは
tdd Step 1 の仕事。本スキルはコードを書かない。
- 既存テストコードのレビュー: test smell・seam・AI 生成パターンの検出は
test-review の担当。
- テスト diff の検出力監査: mutation に対する検出力チェックは
test-mutation-gate の担当。boundary-gap warn が出た場合の再導出はここに戻ってくる。
- 仕様そのものの決定: 対象の振る舞い自体を決めるのは
design / software-design。本スキルは確定した契約からケースを導出するだけ。
- property-based ツールの実装詳細: Hypothesis (Python) 固有の書き方・shrinking 設定は
test-review の references/python.md に委譲し、重複させない。fast-check (JS/TS) 等、本カタログに専用リファレンスが無いツールは各ツールの公式ドキュメントに委ねる。本スキルは「どの property を選ぶか」の導出方法論に留める。
- テストピラミッドの事後レビュー: 書かれたテストの配分が妥当かの事後チェックは
test-review §9。本スキルは書く前の配分判断に限定する。
既知の限界
- 技法の優先順位づけは判断を要する: 1 つの対象に複数技法が同時に該当する場合、どれを主にするかは対象のリスクプロファイル次第。本スキルは決定表で候補を絞るところまでで、最終判断の重みづけ基準までは固定しない。
- ペアワイズ生成ツールの使い方は範囲外: PICT 等の具体的なツール実行は対象外。技法として選んだ後の生成作業は実行者に委ねる。
- 契約が事前に文書化されていない対象では精度がヒアリング依存: コードコメントや仕様書がない場合、Step 1 のヒアリング精度が設計表全体の質を決める。
- 非機能要求（性能・セキュリティ）専用の設計技法は薄い: 本スキルが取り込むのは機能的振る舞いの導出技法 4 系統のみ。脅威モデリングや性能要件からのテスト導出は範囲外。
リファレンス
references/classical-techniques.md — 同値分割・境界値分析・デシジョンテーブル・状態遷移テスト・ペアワイズ/組合せテストの手順と選択基準references/contracts-and-properties.md — 契約 (Hoare 論理) からの導出手順と property-based testing の taxonomyreferences/test-sizes.md — Google Software Engineering の Test Sizes 配分判断
