propose-feature-test-plan

Propose Feature Test Plan Skill

目的

要件と制約を具体的なテストに体系的にマッピングするテスト計画を作成します。これにより、すべての要件に検証方法が割り当てられ、テスト実装のガイドとなります。

使用タイミング

• デザインドキュメントに重要な制約（Critical Constraints）が存在する場合
• 実装前のテスト計画立案の準備ができた場合
• 各要件を検証するテストを文書化する必要がある場合

前提条件

• 機能コンセプトが ./docs/features/NNNN-feature-name/concept.md に存在すること
• 要件が ./docs/features/NNNN-feature-name/requirements.md に存在すること
• デザイン（重要な制約を含む）が ./docs/features/NNNN-feature-name/design.md に存在すること

手順

1. 前提条件の確認

ls ./docs/features/NNNN-feature-name/concept.md
ls ./docs/features/NNNN-feature-name/requirements.md
ls ./docs/features/NNNN-feature-name/design.md

いずれかが存在しない場合は、先にそのステップを完了してください。

2. 要件と制約の抽出

requirements.md からすべての REQ-* 識別子を確認します。 design.md からすべての CC-* 重要な制約を確認します。

3. テスト計画ファイルの作成

以下の構造で ./docs/features/NNNN-feature-name/test-plan.md を作成します。

# テスト計画: 機能名

## 概要

テストアプローチの簡単な説明。

## テストタイプ

- **ユニット**: 内部ロジックを独立してテスト（モック可）
- **統合**: 実際の外部リソース（ファイルシステム、ネットワーク）にアクセス（モック不可）
- **テスト不可**: 自動テストで検証できない場合（理由を説明）
- **対象外**: 外部認証が必要な場合（文書化するが実装しない）

## 要件カバレッジ

| 要件ID | テストタイプ | テスト名 | 説明 |
|--------|------------|----------|------|
| REQ-1  | unit      | test_xxx  | 検証内容 |
| REQ-2  | integration | test_yyy | 検証内容 |
| REQ-3  | not-testable | - | テストできない理由 |
| REQ-4  | out-of-scope | - | 対象外の理由 |

## 重要な制約の検証

| 制約ID | 検証方法 | テスト名 |
|--------|----------|----------|
| CC-1  | 制約の検証方法 | test_xxx |

## 統合テスト要件

CLIプログラムの場合、統合テストは以下の条件を満たす必要があります。
- ユーザーが実行する実際のCLIバイナリ/コマンドを使用する
- 内部APIを直接テストしない
- ユーザー/顧客が実際に行う操作を実行する

## テスト実装に関する注意

これらのテストを実装する際の具体的なガイダンス。

4. 各要件のマッピング

requirements.md の各 REQ-* に対して:

1. テストタイプを決定:

   • ユニット: 内部ロジック、アルゴリズム、データ変換
   • 統合: ファイルI/O、ネットワーク呼び出し、CLIコマンド、外部プロセス
   • テスト不可: 自動化できない場合（主観的な品質、人間の判断が必要、セットアップが困難など）
   • 対象外: 外部システム（クラウドAPI、認証が必要なレジストリなど）との認証が必要な場合

2. テスト名を説明的に付ける（例: test_parses_valid_config）

3. 検証内容の簡単な説明を書く

5. 各重要な制約のマッピング

design.md の各 CC-* に対して:

1. 制約の検証方法を記述する
2. それを実施する特定のテスト名をリンクする
3. 自動テストではなくコードレビューが必要な場合を記載する

6. CLIテストアプローチの文書化

機能にCLIコマンドが含まれる場合:

• 統合テストは実際のバイナリを実行する
• 検証のために stdout/stderr をキャプチャする
• 実際のユーザーワークフローをエンドツーエンドでテストする
• CLIレイヤーをモックしない

7. 対象外テストのマーク

外部認証が必要なテストの場合:

1. 何をテストするかを文書化する
2. 対象外の理由を説明する
3. 手動検証手順があれば記載する

検証

# ファイルの存在確認
ls ./docs/features/NNNN-feature-name/test-plan.md

# すべての要件がカバーされていることを確認
grep -c "REQ-" ./docs/features/NNNN-feature-name/test-plan.md
grep -c "REQ-" ./docs/features/NNNN-feature-name/requirements.md
# カウントが一致することを確認

# すべての制約がカバーされていることを確認
grep -c "CC-" ./docs/features/NNNN-feature-name/test-plan.md
grep -c "CC-" ./docs/features/NNNN-feature-name/design.md
# カウントが一致することを確認

よくある問題

カバレッジ不足: すべての REQ-* と CC-* がテスト計画に含まれている必要があります。検証用のgrepコマンドを使用して確認してください。

誤ったテストタイプ: ユニットテストはファイルシステム/ネットワークにアクセスしてはいけません。統合テストはモックを使用してはいけません。

内部ではなく振る舞いのテスト: CLIツールの場合、内部関数ではなく、ユーザーが実行するCLIコマンドをテストしてください。

あいまいな説明: テストの説明は、検証する具体的な振る舞いを明確に述べてください。

次のステップ

テスト計画を作成した後:

1. 関係者とカバレッジをレビューする
2. propose-implementation-plan スキルに進み、実装計画を立案する
3. 実装計画は test-plan.md をテスト要件として参照すること