backend-test-planner

name	backend-test-planner
description	実装前 or 実装後にテスト戦略を立てる。どの層に何をテストするか、ケースの網羅性、既存基盤の活用方針を計画書化する。実装スキルには踏み込まず、テストの設計に集中する。「テスト戦略立てて」「テスト計画書いて」などで起動。

Test Planner

テストコードを書く前に、何をテストするか を設計する。

いつ使うか

• 新機能を実装する前（TDD 的に先に設計）
• 既存機能のテストが薄くて網羅性を見直したい
• バグ修正後に再発防止テストを計画したい
• レビューで「テストが足りない」と言われたが何を足すべきか分からない

実行手順

1. スコープ確認

• 対象: クラス / 関数 / 機能 / 画面 / エンドポイント のどの粒度か
• 既存テストの有無と場所
• 仕様書 (docs/spec/) の該当セクション

2. テスト層の選定

一般的な層:

層	守備範囲	コスト
Unit	単一関数・クラスのロジック	低
Integration	複数モジュール結合・DB/外部サービス	中
Contract	API・スキーマの外部契約	中
E2E	ユーザー目線の通しシナリオ	高

層の選び方

• ロジックの複雑さ がある場所 → Unit で網羅
• 境界（DB、外部 API、キュー）を越える処理 → Integration
• 外部との契約（公開 API、プラグイン IF）→ Contract
• ユーザー価値そのもの → E2E を最小限

すべての層で重複して書くのは無駄。テストピラミッド（下が厚く、上が薄い）を守る。

3. ケースの洗い出し

仕様書のルール ID（R-01 など）があれば、それを軸に:

• 正常系: 主要な成功パス
• 異常系: バリデーションエラー、権限エラー、外部依存失敗
• 境界: 空配列、0、最大値、null、同時実行
• 状態遷移: 前状態 × イベント → 後状態 の組み合わせ

4. カバレッジの方針

• 数値目標は置かない（80% などに意味はない）
• 代わりに「ルール R-xx が XX テストで検証されている」という対応関係を作る

5. 既存資産の活用

• テストヘルパー / フィクスチャ / モック
• テストランナー / CI 設定
• Test Data Builder がある場合はそれを使う

新規にテスト基盤を作る前に、既存のやり方に乗る ことを確認する。

6. 計画書テンプレート

docs/work/YYYYMMDD_<feature>_test_plan.md として作成（または既存の work 文書内に追記）:

# <機能名> テスト計画

## 対象
<テスト対象の機能 / ファイル>

## 層の選定

| 層 | 担当範囲 | 理由 |
| --- | --- | --- |
| Unit | <範囲> | <なぜここでカバーするか> |
| Integration | <範囲> | ... |
| E2E | <範囲> | ... |

## テストケース

### Unit

| ID | ケース | 対応ルール | 備考 |
| --- | --- | --- | --- |
| UT-01 | 正常系: <ケース> | R-01 | |
| UT-02 | 異常系: <ケース> | R-02 | |
| UT-03 | 境界: <ケース> | - | 空入力 |

### Integration

| ID | ケース | 対応ルール | 備考 |
| --- | --- | --- | --- |
| IT-01 | ... | ... | DB 永続化確認 |

### E2E

| ID | シナリオ | 備考 |
| --- | --- | --- |
| E2E-01 | <ユーザー操作シナリオ> | 主要パスのみ |

## カバレッジ方針

- R-01 〜 R-10 の全ルールに対応するテストを 1 本以上用意
- 境界条件（空・最大・null）は UT 層で網羅
- 本番依存（外部 API）は Integration でモック、E2E は本番 API スタブ

## 活用する既存資産

- <path> — <何を使うか>

## オープン課題

- [ ] <テスト対象だが方針未決>

7. ユーザー確認

計画を提示して承認を得る:

このテスト計画で良いですか？

特に確認:
- E2E を 1 本だけにしていますが増やすべきですか？
- IT-03 で外部 API は本物を使いますか？スタブにしますか？

承認を得てから実装（backend-test-writer 等）に進む。

やらないこと

• テストコードを書く（計画のみ）
• 既存テストの書き直し（それは実装スキルの領分）
• 「とりあえずカバレッジ 100%」のような盲目的目標

関連

• backend-test-writer — Unit ケース(mock 前提)を書く
• backend-integration-test-writer — Integration ケース(実 DB 起動、Handler → Repository を貫通)を書く
• backend-test-gap-finder — unit / integration の両面で不足箇所を洗い出す
• backend-spec-creator — ルール ID の発生源
• backend-work-planner — 実装計画書のテスト戦略セクションを拡張する場合

計画段階で Unit と Integration の担当範囲を表にしておくと、書く段で writer を使い分けるときに迷わない。