---
description: TDD開発のためのテストケース洗い出しを行います。整理された要件に基づいて包括的なテストケースを特定します。
---
あなたはテスト設計の担当者です。指定されたtask_idの要件を確認して。網羅的なテストケースを作成してください。

# TDDテストケースの洗い出し

先ほど整理した要件に基づいて、要件網羅率と機能網羅率が十分に高いテストケースを洗い出します。

## 事前準備

開発コンテキストの準備を行います：

1. **追加ルールの読み込み**
   - `docs/rule` ディレクトリが存在する場合は読み込み
   - `docs/rule/tdd` ディレクトリが存在する場合は読み込み  
   - `docs/rule/tdd/testcases` ディレクトリが存在する場合は読み込み
   - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用

2. **@agent-symbol-searcher でテスト関連情報を検索し、見つかったファイルを読み込み**
   - 既存のテストパターンやテストケースを検索し、該当テストファイルをReadツールで読み込み
   - 類似機能のテスト方法やモック戦略を特定し、関連ファイルをReadツールで読み込み
   - テストフレームワークの使用方法を確認し、設定ファイルをReadツールで読み込み

3. **関連ファイルを直接読み込み**
   - `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴を確認
   - `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` - 要件定義を確認
   - `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` - 既存のテストケースを確認
   - 関連する設計文書やタスクファイルも必要に応じて読み込み

読み込み完了後、準備されたコンテキスト情報を基にテストケースの洗い出しを行います。

## 信頼性レベル指示

各テストケースの作成時には、元の資料（要件定義、既存実装、ライブラリドキュメント等）との照合状況を以下の信号で必ずコメントしてください：

- 🔵 **青信号**: 元の資料を参考にしてほぼ推測していない場合
- 🟡 **黄信号**: 元の資料から妥当な推測の場合
- 🔴 **赤信号**: 元の資料にない推測の場合

## テストケースの分類

### 1. 正常系テストケース（基本的な動作）

以下の形式で記載してください：

- **テスト名**: [わかりやすい日本語名]
  - **何をテストするか**: [このテストで確認したい具体的な動作や機能]
  - **期待される動作**: [どのような処理が正常に実行されるべきか]
- **入力値**: [具体的な値]
  - **入力データの意味**: [なぜこの入力値を選んだか、何を代表しているか]
- **期待される結果**: [具体的な期待値]
  - **期待結果の理由**: [なぜこの結果が正しいとされるか]
- **テストの目的**: [何を確認するか]
  - **確認ポイント**: [特に注意して検証すべき点]
- 🔵🟡🔴 このテストケースの信頼性レベルを記載

### 2. 異常系テストケース（エラーハンドリング）

- **テスト名**: [わかりやすい日本語名]
  - **エラーケースの概要**: [どのような異常状況を想定しているか]
  - **エラー処理の重要性**: [なぜこのエラーハンドリングが必要か]
- **入力値**: [不正な値や境界を超えた値]
  - **不正な理由**: [なぜこの入力値が不正とされるか]
  - **実際の発生シナリオ**: [実運用でどのような場面で発生するか]
- **期待される結果**: [適切なエラーメッセージや例外]
  - **エラーメッセージの内容**: [ユーザーにとって分かりやすいメッセージか]
  - **システムの安全性**: [エラー時にシステムが安全な状態を保てるか]
- **テストの目的**: [エラーハンドリングの確認]
  - **品質保証の観点**: [このテストがシステム品質にどう貢献するか]
- 🔵🟡🔴 このテストケースの信頼性レベルを記載

### 3. 境界値テストケース（最小値、最大値、null等）

- **テスト名**: [わかりやすい日本語名]
  - **境界値の意味**: [なぜこの値が境界として重要か]
  - **境界値での動作保証**: [境界付近での動作の一貫性確認]
- **入力値**: [境界値]
  - **境界値選択の根拠**: [なぜこの値を境界値として選んだか]
  - **実際の使用場面**: [実運用でこの境界値がどう影響するか]
- **期待される結果**: [境界での動作]
  - **境界での正確性**: [境界値での計算や処理が正確に行われるか]
  - **一貫した動作**: [境界の内側と外側で動作が一貫しているか]
- **テストの目的**: [境界条件の確認]
  - **堅牢性の確認**: [システムが極端な条件下でも安定動作するか]
- 🔵🟡🔴 このテストケースの信頼性レベルを記載

## 開発言語・フレームワーク

実装に使用する言語・テストフレームワークも併せて指定してください：

- **プログラミング言語**: {{language}}
  - **言語選択の理由**: [なぜこの言語を選んだか]
  - **テストに適した機能**: [この言語のテストに有利な特徴]
- **テストフレームワーク**: {{test_framework}}
  - **フレームワーク選択の理由**: [なぜこのテストフレームワークを選んだか]
  - **テスト実行環境**: [どのような環境でテストを実行するか]
- 🔵🟡🔴 この内容の信頼性レベルを記載

## テストケース実装時の日本語コメント指針

各テストケースの実装時には以下の日本語コメントを必ず含めてください：

### テストケース開始時のコメント

```javascript
// 【テスト目的】: [このテストで何を確認するかを日本語で明記]
// 【テスト内容】: [具体的にどのような処理をテストするかを説明]
// 【期待される動作】: [正常に動作した場合の結果を説明]
// 🔵🟡🔴 この内容の信頼性レベルを記載
```

### Given（準備フェーズ）のコメント

```javascript
// 【テストデータ準備】: [なぜこのデータを用意するかの理由]
// 【初期条件設定】: [テスト実行前の状態を説明]
// 【前提条件確認】: [テスト実行に必要な前提条件を明記]
```

### When（実行フェーズ）のコメント

```javascript
// 【実際の処理実行】: [どの機能/メソッドを呼び出すかを説明]
// 【処理内容】: [実行される処理の内容を日本語で説明]
// 【実行タイミング】: [なぜこのタイミングで実行するかを説明]
```

### Then（検証フェーズ）のコメント

```javascript
// 【結果検証】: [何を検証するかを具体的に説明]
// 【期待値確認】: [期待される結果とその理由を説明]
// 【品質保証】: [この検証がシステム品質にどう貢献するかを説明]
```

### 各expectステートメントのコメント

```javascript
// 【検証項目】: [この検証で確認している具体的な項目]
// 🔵🟡🔴 この内容の信頼性レベルを記載
expect(result.validPaths).toHaveLength(2); // 【確認内容】: 有効なパスが正確に2つ検出されることを確認
expect(result.invalidPaths).toContain('nonexistent.json'); // 【確認内容】: 存在しないファイルが無効パスとして適切に分類されることを確認
```

### セットアップ・クリーンアップのコメント

```javascript
beforeEach(() => {
  // 【テスト前準備】: [各テスト実行前に行う準備作業の説明]
  // 【環境初期化】: [テスト環境をクリーンな状態にする理由と方法]
});

afterEach(() => {
  // 【テスト後処理】: [各テスト実行後に行うクリーンアップ作業の説明]
  // 【状態復元】: [次のテストに影響しないよう状態を復元する理由]
});
```

すべて洗い出したら以下を実行してください：

1. テストケース一覧を `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` に保存（既存ファイルがある場合は追記）
2. TODOステータスを更新（テストケース洗い出し完了をマーク）
3. **品質判定**: テストケースの品質を以下の基準で判定
   - テストケース分類: 正常系・異常系・境界値が網羅されている
   - 期待値定義: 各テストケースの期待値が明確
   - 技術選択: プログラミング言語・テストフレームワークが確定
   - 実装可能性: 現在の技術スタックで実現可能
4. **次のステップ表示**: 判定結果に関わらず、次のお勧めコマンドを表示
   - 「次のお勧めステップ: `/tsumiki:tdd-red` でRedフェーズ（失敗テスト作成）を開始します。」

## 品質判定基準

以下の基準でテストケースの品質を判定します：

```
✅ 高品質:
- テストケース分類: 正常系・異常系・境界値が網羅されている
- 期待値定義: 各テストケースの期待値が明確
- 技術選択: プログラミング言語・テストフレームワークが確定
- 実装可能性: 現在の技術スタックで実現可能

⚠️ 要改善:
- テストケースに漏れや重複がある
- 期待値が曖昧または不十分
- 技術選択に迷いがある
- 複雑すぎて実装困難

❌ 不適切:
- 要件との整合性が取れていない
- テストケースが不足している
- 技術的実現性に問題がある
```

## TODO更新パターン

```
- 現在のTODO「テストケース洗い出し」を「completed」にマーク
- テストケース定義フェーズの完了をTODO内容に反映
- 品質判定結果をTODO内容に記録
- 次のフェーズ「Redフェーズ（失敗テスト作成）」をTODOに追加
```