test-driven-design

テスト設計・実装・レビュー スキル

このスキルは、質の高いテストを設計・実装・レビューするためのワークフローを提供する。 背景にある思想は references/testing-principles.md に詳述されている。

核心原則(常に意識する)

テストの価値は4本の柱の 掛け算 で決まる。どれか1つでもゼロなら価値はゼロ。

テストの価値 = 退行に対する保護 × リファクタリングへの耐性 × 迅速なフィードバック × 保守のしやすさ

判断に迷ったら以下の優先順位に従う

1. リファクタリングへの耐性 — 絶対に妥協しない(偽陽性はテストへの信頼を破壊する)
2. 保守のしやすさ — 妥協しない
3. 退行に対する保護 と 迅速なフィードバック — テスト種別に応じて調整

ワークフロー

ユーザーのリクエストに応じて、以下の3フェーズのうち必要なものを実行する。 すべてを毎回やる必要はない。ユーザーが「テストを書いて」と言えば「洗い出し→実装」、 「テストを見直して」と言えば「レビュー」、のように柔軟に対応する。

---

テストケースの洗い出し

対象コードを読み、テストすべきケースを特定する。

コードを4分類する

分類	複雑さ/重要性	協力者の数	テスト方針
ドメインモデル / アルゴリズム	高い	少ない	単体テストの最優先対象
取るに足らないコード	低い	少ない	テストしない
コントローラ	低い	多い	統合テストで検証
過度に複雑なコード	高い	多い	リファクタリングで分割してからテスト

• 1行プロパティ、引数なしコンストラクタなど「取るに足らないコード」はテスト対象から除外する
• 「過度に複雑なコード」を見つけたら、テストを書く前にリファクタリングを提案する

テスト対象外の明示的カテゴリ

以下に該当するものはテスト対象から除外する。退行保護の価値がゼロに等しい。

カテゴリ	説明
言語・ランタイムの保証	使用言語やランタイムが仕様として保証する振る舞い(例外送出・配列操作の順序保証・型変換など)
外部ライブラリの内部挙動	利用しているライブラリ・フレームワークの実装詳細(ORMのクエリ生成ロジック、テストランナーのアサーション内部動作など)

テストケースを列挙する

仕様・データフローが不明瞭な箇所はその都度ユーザーに確認してから進める。

テストケースは describe と it.todo を使い、階層構造とケース名のみを定義したコードブロックで提示する。

describe("割引計算", () => {
  describe("正常系", () => {
    describe("会員ランクによる割引", () => {
      it.todo("ゴールド会員の場合、20%割引が適用されること")
      it.todo("シルバー会員の場合、10%割引が適用されること")
    })
  })
  describe("異常系", () => {
    describe("無効な入力値", () => {
      it.todo("注文金額が0以下の場合、エラーが発生すること")
    })
  })
})

テストケース名の規則:

• 「〜の時、〜であること」という形式で振る舞いを明確に表現する
• テストケース名の集合がそのまま機能の仕様書として読めるよう、流暢な日本語で記述する
• 非開発者にも伝わる普通の言い回しで事実を表現する
• テスト対象のメソッド名はテスト名に含めない
• IsDeliveryValid_InvalidDate_ReturnsFalse のような形式的命名は使わない
• モックの利用を前提としたテストケースは作らない

テスト手法の選定(優先順):

1. 出力値ベース・テスト(最優先 — 戻り値のみ検証、最も保守しやすい)
2. 状態ベース・テスト(処理後の最終状態を検証)
3. コミュニケーション・ベース・テスト(管理下にない外部依存へのモック検証のみ)

優先度の判定基準:

• 高: ビジネス上重要 + 複雑なロジック
• 中: 複雑だがビジネス影響が限定的 / ビジネス重要だが単純
• 低: あれば安心だが必須ではない

契約プログラミングの観点でテストケースを補完する

テストケースを列挙したら、以下の3つの観点でカバレッジを確認する

観点	説明	テストケースの例
事前条件	関数・メソッドが正しく動作するために、呼び出し側が満たすべき条件	引数が null / 範囲外の値が渡された場合
事後条件	正常終了後に必ず成立すべき保証	戻り値が期待の型・範囲内にある、副作用が正しく反映される
不変条件	オブジェクトのライフタイムを通じて常に成立すべき性質	処理前後でオブジェクトの整合性が保たれる

• 事前条件の違反は 異常系テストケース として列挙する
• 事後条件の保証は 正常系テストケース として列挙する
• 不変条件は 状態ベーステスト で検証する

契約設計における検証の徹底:

• 事後条件: Actで得た戻り値(出力値)と、副作用がある場合はその後の状態の両方をアサートする
• 不変条件: 異常系テストでは、エラーが発生することの検証に加えて「Act実行前後で状態が変わっていないこと(中途半端に更新・削除されていないこと)」もアサートに含める

ユーザーに提示し、合意を得てからフェーズ2に進む。

---

テストの実装

フェーズ1で合意した describe / it.todo のアウトラインをベースに実装する。 describe の構造とテストケース名(ドキュメントとしての意図)はそのまま維持し、it.todo を実行可能な it に変換する。

注意: 実装コードが期待通りの振る舞いをしていない可能性がある。テスト実装中に実装の誤りやバグの疑いに気づいた場合は、テストを書き進める前にユーザーにコメントして確認する。

グルーピング構造を維持する

フェーズ1で定義した describe 階層をそのまま使う。構造を変える場合はユーザーに確認する。 グルーピングの粒度はビジネスの文脈に合わせる。「このグループを読めばどんな前提条件・シナリオか分かる」という単位を意識する。

AAA パターンで構造化する

すべてのテストを以下の構造で書く。各フェーズは空行で区切る

test("会員ランクがゴールドの場合20%割引が適用される", () => {
  // Arrange(準備)
  const sut = createPricingService()
  const order = createOrder({ memberRank: "gold", amount: 10000 })

  // Act(実行)
  const result = sut.calculateDiscount(order)

  // Assert(確認)
  expect(result).toBe(2000)
})

実装チェックリスト

• テスト対象の変数名は sut にする(System Under Test の略、慣例的にテスト対象を指す)
• Act フェーズは原則1行(2行以上ならカプセル化の破綻を疑う)
• 期待値はリテラルでハードコードする(テスト内でロジックを再実装しない)
• 共通の準備コードはファクトリメソッドに抽出する(コンストラクタでの共通化は避ける)
• 1テスト = 1振る舞い(複数の Act フェーズを含めない)
• パラメータ化テスト: 正常系と異常系は別々にする

モックの使用判断

依存の種類	扱い	理由
管理下にある依存(専用DB等)	実物を使い、最終状態を検証	モック化するとリファクタリング耐性が失われる
管理下にない依存(外部API、メッセージバス等)	モックで最終出力を検証	外部との通信は観察可能な振る舞い
共有依存(テスト間で共有される状態)	テスト・ダブルに置き換える	テスト間の干渉を防ぐ

重要: 単体テストではモックを使わない。モックは統合テストで管理下にない依存に対してのみ使用する。

スタブとモックの区別

• スタブ: テスト対象にデータを提供する(入力方向)→ 検証してはいけない
• モック: テスト対象の出力を検証する(出力方向)→ 検証する

スタブへの呼び出しを検証するのはアンチパターン(過剰検証)。

テスト実行と修正

テスト実装後、テストを実行して結果を確認する。 失敗したテストがあれば、以下の順で原因を切り分ける

1. テストコードの誤り(期待値の間違い、準備不足)→ テストを修正
2. プロダクションコードのバグ → ユーザーに報告し、修正方針を相談
3. 設計上の問題(テストしにくい構造)→ リファクタリングを提案
4. テストと実装のどちらが誤りか判断できない → テストをスキップしてユーザーに確認する

全件パスするまでこのサイクルを繰り返す。

---

既存テストのレビュー(及び削除)

既存テストを読み、以下の観点で評価する。

削除候補の特定

以下に該当するテストは削除を提案する

問題	説明	例
実装の詳細を検証している	内部メソッドの呼び出し順序・回数を検証	expect(mock).toHaveBeenCalledTimes(3) で内部手順を確認
取るに足らないコードのテスト	1行プロパティや自明なコードのテスト	getter/setter のテスト
スタブを検証している	入力用のテスト・ダブルへの呼び出しを検証	データ取得用スタブの呼び出し回数を検証
テスト内でドメイン知識を再実装	期待値をロジックで算出している	expect(result).toBe(price * taxRate)
private メソッドを直接テスト	テストのために private を public に変更	内部ヘルパーの直接テスト
private 状態を公開してテスト	テストのために内部状態を public に変更	内部フラグの直接検証

改善提案

削除ではなく改善が適切な場合

• 偽陽性が出やすいテスト → 観察可能な振る舞いのみ検証するよう書き換え
• AAA パターンに従っていない → 構造を整理
• テスト名が形式的 → 事実を伝える名前に変更
• Act フェーズが複数行 → カプセル化の改善を提案
• コミュニケーション・ベースで書かれている → 出力値ベースまたは状態ベースへの書き換えを検討

レビュー結果の報告

以下の形式で報告する

## テストレビュー結果

### 削除推奨
| ファイル:行 | テスト名 | 理由 |
|---|---|---|

### 改善推奨
| ファイル:行 | テスト名 | 現在の問題 | 改善案 |
|---|---|---|---|

### 問題なし
| ファイル:行 | テスト名 | 評価 |
|---|---|---|

ユーザーの合意を得てから削除・修正を実行する。

---

「観察可能な振る舞い」の判断基準

テストで何を検証すべきかの判断に迷ったら、この基準を適用する

• 観察可能な振る舞い: クライアントが目標達成に直接使う公開操作・公開状態
• 実装の詳細: 上記以外のすべて(public であっても該当しうる)

判別方法: 「クライアントが1つの目標を達成するために、複数メソッドを順番に呼ぶ必要があるか？」 → Yes なら実装の詳細が漏洩している。テストではなく設計の改善を提案する。

---

テスト・ピラミッドの適用

     /  E2E  \        ← 最小限。保護と耐性は最大だがフィードバックが遅い
    /  統合   \       ← ハッピーパスと単体で検証できないケースのみ
   /  単体テスト \    ← 最多。ドメインモデル/アルゴリズムを高速に検証

すべての層でブラックボックステスト(観察可能な振る舞いのみ検証)を徹底する。

詳細リファレンス

原則の詳細や背景理論が必要な場合は references/testing-principles.md を参照する。