TDD開発のテストケース洗い出しを実施し、要件定義書を参照しながら網羅的なテストケースを作成します。信頼性レベルを示しながらテストケースを定義します。
Generates comprehensive TDD test cases from requirements with reliability level indicators.
/plugin marketplace add classmethod/tsumiki/plugin install tsumiki@tsumikiTDD開発のテストケース洗い出しを実施し、要件定義書を参照しながら網羅的なテストケースを作成します。信頼性レベルを示しながらテストケースを定義します。
出力ディレクトリ="./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
開発コンテキストの準備を実行する： 既存の実装ドキュメントの確認
./docs/implements/{要件名}/{{task_id}}/ ディレクトリ内の全てのMDファイルを確認note.md - タスクノート（技術スタック、開発ルール、関連実装）{feature_name}-requirements.md - 既存の要件定義{feature_name}-testcases.md - 既存のテストケース{feature_name}-memo.md - 開発履歴メモタスクノートの読み込み
./docs/implements/{要件名}/{{task_id}}/note.md が存在しない場合:
/tsumiki:tdd-tasknote {要件名} {{task_id}} コマンドを実行してノートを生成追加ルールの読み込み
./docs/rule ディレクトリが存在する場合は読み込み./docs/rule/tdd ディレクトリが存在する場合は読み込み./docs/rule/tdd/testcases ディレクトリが存在する場合は読み込み@agent-symbol-searcher でテスト関連情報を検索し、見つかったファイルを読み込み
関連ファイルを直接読み込み
./docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md - 既存の開発履歴を確認./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md - 要件定義を確認./docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md - 既存のテストケースを確認読み込み完了後、step3 を実行する
<testcases_template> の内容を context の情報で埋めて、テストケースを直接作成する
作成したテストケースの内容について、品質判定基準に基づいて以下を評価：
品質判定結果をユーザーに表示する
step4 を実行する
/tsumiki:tdd-red {要件名} {{TASK-ID}} でRedフェーズ（失敗テスト作成）を開始します。」docs/implements/{要件名}/{task_id}/{feature_name}-testcases.mddocs/implements/user-auth/task-001/login-testcases.md✅ 高品質:
- テストケース分類: 正常系・異常系・境界値が網羅されている
- 期待値定義: 各テストケースの期待値が明確
- 技術選択: プログラミング言語・テストフレームワークが確定
- 実装可能性: 現在の技術スタックで実現可能
- 信頼性レベル: 🔵（青信号）が多い
⚠️ 要改善:
- テストケースに漏れや重複がある
- 期待値が曖昧または不十分
- 技術選択に迷いがある
- 複雑すぎて実装困難
- 信頼性レベル: 🟡🔴（黄・赤信号）が多い
❌ 不適切:
- 要件との整合性が取れていない
- テストケースが不足している
- 技術的実現性に問題がある
- 現在のTODO「テストケース洗い出し」を「completed」にマーク
- テストケース定義フェーズの完了をTODO内容に反映
- 次のフェーズ「Redフェーズ（失敗テスト作成）」をTODOに追加
- 品質判定結果をTODO内容に記録
各テストケースについて、元の資料（要件定義、既存実装、ライブラリドキュメント等）との照合状況を以下の信号でコメントしてください：
/Users/username/projects/myapp/src/utils/helper.tssrc/utils/helper.ts<testcases_template> あなたはテスト設計の担当者です。以下の情報に基づいて、網羅的なテストケースを作成してください。
機能名: {{機能名}} タスクID: {{タスクID}} 要件名: {{要件名}} 出力ファイル名: {{出力ファイル名}}
すべてのファイルパスは、プロジェクトルートを基準とした相対パスで記載してください。 絶対パス（/Users/... や C:... など）は使用しないでください。
例:
/Users/username/projects/myapp/src/utils/helper.tssrc/utils/helper.ts既に読み込まれた以下のコンテキスト情報を活用してください：
note.md）
{feature_name}-requirements.md）
docs/rule, docs/rule/tdd, docs/rule/tdd/testcases）これらの情報を基に、以下のフォーマットでテストケースを作成してください。
【信頼性レベル指示】: 各テストケースについて、元の資料（要件定義、既存実装、ライブラリドキュメント等）との照合状況を以下の信号でコメントしてください：
以下の形式で記載してください：
実装に使用する言語・テストフレームワークも併せて指定してください：
各テストケースの実装時には以下の日本語コメントを必ず含めてください：
// 【テスト目的】: [このテストで何を確認するかを日本語で明記]
// 【テスト内容】: [具体的にどのような処理をテストするかを説明]
// 【期待される動作】: [正常に動作した場合の結果を説明]
// 🔵🟡🔴 この内容の信頼性レベルを記載
// 【テストデータ準備】: [なぜこのデータを用意するかの理由]
// 【初期条件設定】: [テスト実行前の状態を説明]
// 【前提条件確認】: [テスト実行に必要な前提条件を明記]
// 【実際の処理実行】: [どの機能/メソッドを呼び出すかを説明]
// 【処理内容】: [実行される処理の内容を日本語で説明]
// 【実行タイミング】: [なぜこのタイミングで実行するかを説明]
// 【結果検証】: [何を検証するかを具体的に説明]
// 【期待値確認】: [期待される結果とその理由を説明]
// 【品質保証】: [この検証がシステム品質にどう貢献するかを説明]
// 【検証項目】: [この検証で確認している具体的な項目]
// 🔵🟡🔴 この内容の信頼性レベルを記載
expect(result.validPaths).toHaveLength(2); // 【確認内容】: 有効なパスが正確に2つ検出されることを確認
expect(result.invalidPaths).toContain('nonexistent.json'); // 【確認内容】: 存在しないファイルが無効パスとして適切に分類されることを確認
beforeEach(() => {
// 【テスト前準備】: [各テスト実行前に行う準備作業の説明]
// 【環境初期化】: [テスト環境をクリーンな状態にする理由と方法]
});
afterEach(() => {
// 【テスト後処理】: [各テスト実行後に行うクリーンアップ作業の説明]
// 【状態復元】: [次のテストに影響しないよう状態を復元する理由]
});
要件定義書を参照した場合、以下の対応関係を明記してください：
上記のフォーマットに従って、テストケースを作成してください。
必ず Write ツールを使用して、{{出力ファイル名}} に結果を保存してください。 既存ファイルがある場合は、内容を追記してください。 </testcases_template>