SpecDojo Handbook

日本語

English

日本語

English

Appearance

単体テスト仕様 対象別 作成の指示テンプレート ​

  • 以下のルールに従って、単体テスト仕様-対象別（uts-<term>） を 1 ファイル作成してください。出力は Markdown とします。
  • UTS は「テストコード」ではありません。単体テストで 何をどこまで保証するか（保証範囲） を明文化する文書です。
  • 本ドキュメント（uts-<term>）は 独立した方針文書ではありません（uts-index を前提）。
  • UTS は 1ドキュメント = 1論理対象（例: 在庫、注文、割引判定）とします。
  • UTS は テストケースの具体値やケース列挙をしません（詳細はテストコードおよび CI アーティファクトへ）。
  • 曖昧表現（例:「十分に」「適切に」「基本的に」「正常に動作すること」）は禁止し、合否判定できる形で記述してください。
  • 関係の表現は part_of と based_on のみを使います（他の関係タイプを増やしません）。
  • 禁止: テストコード全文、SQL、物理テーブル/物理カラム名、実装クラス/関数名、クリック手順など UI 操作の逐語列挙、テストケース番号の羅列、TPC の観点・条件表の再掲（ID参照に留める）、スキーマ未定義のメタ情報プロパティ追加

事前に与えられる情報（入力） ​

次の情報が与えられている前提で、それに整合する UTS を生成してください（不明な場合は「未確定」として明記してよい）。

  • 対象（用語集 GL の term と論理名）
  • 対象の責務（何を担当し、何を担当しないか）
  • 上位仕様 ID
    • 必須: uts-index
    • 必須: 関連する tpc-*
    • 任意: bac-* / br-* / nfr-* など

ファイル命名・ID規則（必須） ​

  • id は uts-<term>（kebab-case。例: uts-inventory）。
  • <term> は 用語集（GL）に定義された term を使用します。

出力フォーマット（必須） ​

YAML Frontmatter（必須） ​

  • 先頭に YAML Frontmatter を付与し、以下の形式で記述してください（id / type / title / status は必須、type は test 固定）。

    yaml
    ---
id: uts-<term>
type: test
title: 単体テスト仕様: <論理名>
status: draft # draft / ready / deprecated
part_of: [uts-index]
based_on:
  - tpc-<...>
supersedes: []
---

  • part_of には 必ず uts-index を含めてください。

  • based_on には 必ず 関連する tpc-* を含めてください。

  • 対象が業務ルールや受入条件に依存する場合は、bac-* / br-* / nfr-* も追加してください（ただし 直接利用したものだけ）。

  • part_of / based_on / supersedes は ID 配列です（未指定は [] 可）。

本文の見出し（必須・順序固定） ​

本文は次の見出し（日本語）をこの順序で必ず含めてください。

  1. 概要
  2. 対象の責務と役割
  3. 単体テストの対象範囲と境界（モック/スタブ方針）
  4. 保証する観点（個別）
  5. テスト条件（代表条件）
  6. 合格基準とエビデンス
  7. 対象外・除外理由
  8. メモ / 将来課題

記述ルール（重要） ​

追跡可能性（TPC からの派生） ​

  • 観点・条件は TPC からの派生であることが追跡可能でなければなりません。
  • 追跡は次で担保してください。
    • Frontmatter の part_of（必須: uts-index）
    • Frontmatter の based_on（必須: tpc-*）
    • 表の「根拠」列に、根拠となる ID（tpc-* / bac-* / br-* など）を記載

観点ID・条件IDの扱い ​

  • 観点IDは TPC の観点ID（例: TP-01）をそのまま参照してください（独自採番しません）。
  • 条件IDはこの文書内で一意であればOKです（例: TC-01）。
  • 他文書から参照する可能性がある場合は、<docId>:<条件ID>（例: uts-inventory:TC-01）のように完全修飾で扱えるようにしてください。

1. 概要 ​

  • 1〜3文で「この対象について、単体テストで何を保証するのか」を書いてください。
  • uts-index の方針との差分・特記事項がある場合は明示してください。

2. 対象の責務と役割（必須） ​

  • 対象の責務を 業務・設計観点で簡潔に説明してください。
  • 推奨: 表形式（対象名、主な責務、関連ルール、上位モデル）。
  • 実装構造（クラス名等）は書きません。

3. 単体テストの対象範囲と境界（モック/スタブ方針）（必須） ​

  • 「対象に含める」「境界で切る」「依存の扱い」を明確にしてください。
  • DB 永続化、外部 API、同時実行制御などは原則として境界外にし、結合/非機能テスト等で担保する前提を明記してください。
  • 推奨: 「対象に含める / 境界で切る / 依存の扱い（モック/スタブ、時刻固定など）」を表形式でまとめてください。

4. 保証する観点（個別）（必須） ​

  • UTS の中核です。観点は「切り口」であり、ケースの羅列にしないでください。
  • 推奨カラム: 参照TPC / 観点ID / 観点分類 / 観点名 / 保証内容 / 追加根拠（任意）
  • 「保証内容」は “何を保証するか（What）” を合否判定可能な粒度で記載してください。
  • TPC の観点定義は SSOT です（TPC の観点・条件表を再掲しません。必要な範囲は ID 参照で示します）。
  • 追加根拠（任意） は、TPC 以外の追加根拠（bac-* / br-* / nfr-* 等）がある場合のみ記載してください（未指定可）。

5. テスト条件（代表条件）（必須） ​

  • 観点ごとに、代表的な条件を 状態レベル で表にしてください。
  • 具体値の大量列挙は禁止です（必要なら“境界値”と書き、詳細はテストコードに委ねる）。
  • 目安: 各観点あたり最大 3 件程度。網羅展開はテストコードに委ねます。
  • 数値・組合せ表・境界値展開はテストコードで表現し、ここでは状態レベルの代表条件に留めてください。

6. 合格基準とエビデンス（必須） ​

  • 共通の合格基準・共通エビデンスは uts-index を正とし、ここには対象固有の「追加基準」「追加エビデンス」「例外的な取り扱い」だけを書いてください。
  • 「何を満たしたら完了か」を判定可能な形で記述し、エビデンス（例: CI のテスト結果）を紐づけてください。

7. 対象外・除外理由（必須） ​

  • 単体では担保しない範囲と、その理由（結合テスト、性能/非機能、E2E 等で担保）を明記してください。

8. メモ / 将来課題 ​

  • 将来追加したい観点、未確定の業務ルール、仕様待ち事項などを箇条書きで記載してください。

最終チェック（自己検査） ​

  • id が uts-<term> 形式で、type: test になっている
  • part_of に uts-index が入っている
  • based_on に関連する tpc-* が入っている
  • 観点/条件の「根拠」に上位仕様 ID が入っていて追跡可能
  • 観点が保証範囲（What）として書けている（ケース集になっていない）
  • 禁止事項（コード/SQL/実装名/曖昧表現/TPC表の再掲）を含めていない
  • 関係タイプは part_of / based_on のみ（他を増やしていない）
  • スキーマ未定義のメタ情報プロパティを追加していない