/tdd-testcases

description: TDD開発のためのテストケース洗い出しを行います。整理された要件に基づいて包括的なテストケースを特定します。
allowed-tools: Read, Glob, Grep, Task, Write, TodoWrite, Edit
argument-hint: "[要件名] [TASK-ID]"

TDD開発のテストケース洗い出しを実施し、要件定義書を参照しながら網羅的なテストケースを作成します。信頼性レベルを示しながらテストケースを定義します。

context

出力ディレクトリ="./docs/implements" 機能名={{feature_name}} タスクID={{task_id}} 要件名={{requirement_name}} 信頼性評価=[] 要件定義ファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md 出力ファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md タスクファイル1=./docs/tasks/{要件名}/{{task_id}}.md タスクファイル2=./docs/tasks/{要件名}-phase*.md タスクoverviewファイル1=./docs/tasks/{要件名}/overview.md タスクoverviewファイル2=./docs/tasks/{要件名}-overview.md

step

• $ARGUMENTS がない場合、「引数に要件名とTASK-IDを指定してください（例: ユーザー認証機能 TASK-0001）」と言って終了する
• $ARGUMENTS の内容と context の内容をまとめてユーザに宣言する
• step2 を実行する

step2

• 開発コンテキストの準備を実行する：

**1. タスクノートの読み込み（唯一のコンテキストソース）**

• `./docs/implements/{要件名}/{{task_id}}/note.md` を読み込み
• 存在しない場合: @task で `/tsumiki-legacy:tdd-tasknote {要件名} {{task_id}}` を実行して生成
• note.mdには技術スタック、開発ルール、関連実装、設計文書、テスト関連情報、注意事項が集約済み

**2. 直前フェーズの出力を読み込み**

• `./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` - 要件定義
• `./docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` - 既存のテストケース（存在する場合）

• 読み込み完了後、step3 を実行する

step3

• <testcases_template> の内容を context の情報で埋めて、テストケースを直接作成する
• 読み込んだコンテキスト情報（タスクノート、要件定義、追加ルール等）を活用
• 信頼性レベル（🔵🟡🔴）を各テストケースに記載
• Write ツールを使用して 出力ファイル に保存（既存ファイルがある場合は追記）

• 作成したテストケースの内容について、品質判定基準に基づいて以下を評価：
• テストケース分類: 正常系・異常系・境界値が網羅されている
• 期待値定義: 各テストケースの期待値が明確
• 技術選択: プログラミング言語・テストフレームワークが確定
• 実装可能性: 現在の技術スタックで実現可能
• 信頼性レベル（🔵🟡🔴の分布）

• 品質判定結果に応じた処理:
• **✅ 高品質**: そのまま step4 へ
• **⚠️ 要改善**: 自動修正ループを実施

1. 要改善の指摘内容（どの項目が不足/不適切か）を特定 2. Task tool (subagent_type: general-purpose) で指摘内容を渡してテストケースを修正させる 3. 修正後のテストケースを Write tool で上書き保存 4. 再度品質判定基準に基づいて評価 5. 高品質になれば step4 へ 6. まだ要改善の場合: もう1回だけ修正を試みる（最大2回まで） 7. 2回修正しても要改善のまま → 警告をtasknoteの注意事項に追記し、step4 へ

• **❌ 不適切**: AskUserQuestion でユーザに確認（「修正して再試行」/「このまま進む」/「中止」）
• step4 を実行する

step4

• TodoWrite ツールで TODO ステータスを更新する
• 現在のTODOを「completed」にマーク
• テストケース定義フェーズの完了をTODO内容に反映
• 次のフェーズ「Redフェーズ（失敗テスト作成）」をTODOに追加
• 品質判定結果をTODO内容に記録
• 次のステップ表示: 「次のお勧めステップ: `/tsumiki-legacy:tdd-red {要件名} {{TASK-ID}}` でRedフェーズ（失敗テスト作成）を開始します。」

rules

ファイル名のルール

出力ファイルのパス形式

• `docs/implements/{要件名}/{task_id}/{feature_name}-testcases.md`
• 例: `docs/implements/user-auth/task-001/login-testcases.md`

ファイル名の命名規則

• 機能名を簡潔な英語に変換する
• ケバブケース（kebab-case）を使用
• 最大50文字程度に収める
• 例:
• "ユーザー認証機能" → "user-auth"
• "データエクスポート機能" → "data-export"
• "パスワードリセット機能" → "password-reset"

品質判定基準

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

⚠️ 要改善:
- テストケースに漏れや重複がある
- 期待値が曖昧または不十分
- 技術選択に迷いがある
- 複雑すぎて実装困難
- 信頼性レベル: 🟡🔴（黄・赤信号）が多い

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

TODO更新パターン

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

信頼性レベル指示

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

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

ファイルパスの記載ルール

• **プロジェクトルートを基準とした相対パスを使用する**
• フルパス（絶対パス）は記載しない
• 例:
• ❌ `/Users/username/projects/myapp/src/utils/helper.ts`
• ✅ `src/utils/helper.ts`

info

<testcases_template> あなたはテスト設計の担当者です。以下の情報に基づいて、網羅的なテストケースを作成してください。

テストケース作成対象の情報

機能名: {{機能名}} タスクID: {{タスクID}} 要件名: {{要件名}} 出力ファイル名: {{出力ファイル名}}

重要な注意事項

**すべてのファイルパスは、プロジェクトルートを基準とした相対パスで記載してください。** **絶対パス（/Users/... や C:\... など）は使用しないでください。**

例:

• ❌ `/Users/username/projects/myapp/src/utils/helper.ts`
• ✅ `src/utils/helper.ts`

テストケース作成手順

既に読み込まれた以下のコンテキスト情報を活用してください：

• **タスクノート**（`note.md`）
• 技術スタック（使用技術・フレームワーク・アーキテクチャパターン）
• 開発ルール（コーディング規約・型チェック・テスト要件）
• 関連実装（既存の実装パターン・参考コード）
• 設計文書（データモデル・ディレクトリ構造）
• 注意事項（技術的制約・セキュリティ要件・パフォーマンス要件）
• **要件定義書**（`{feature_name}-requirements.md`）
• 機能の概要
• 入力・出力の仕様
• 制約条件
• 想定される使用例
• 追加ルール（`docs/rule`, `docs/rule/tdd`, `docs/rule/tdd/testcases`）
• 既存のテストケース・テストパターン

これらの情報を基に、以下のフォーマットでテストケースを作成してください。

TDD用テストケースフォーマット

**【信頼性レベル指示】**: 各テストケースについて、元の資料（要件定義、既存実装、ライブラリドキュメント等）との照合状況を以下の信号でコメントしてください：

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

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

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

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

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

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

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

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

4. 開発言語・フレームワーク

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

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

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

各テストケ