gh-classmethod-tsumiki/commands/tdd-verify-complete.md

description

description
TDD開発でテストケースの実装が完全に完了しているかを検証します。すべてのテストが通ることを確認し、開発完了を保証します。

TDD テストケース完全性検証

TDD開発でテストケースの実装が完全に完了しているかを検証します。

検証の目的

リファクタリング後に、予定していたテストケースがすべて実装されているかを確認し、実装漏れを防ぎます。

重要な原則

⚠️ この工程では修正を行わない

• この検証フェーズではコードやテストの修正は一切行わない
• 問題を発見した場合は内容をmemoファイルに記載する
• 修正作業は後の工程（次のTDDサイクルや別のタスク）に委ねる
• 検証・記録・報告に専念する
• テストの実行は @task で実行する
• NEVER 全体のテストケースの実装率と成功率のレポートは省略しない

検証手順

1. 既存テストのグリーン状態確認

• 必須: 全ての既存テストが成功していることを確認
• npm test または jest を実行してテスト結果を確認
• テスト失敗がある場合: memoファイルに記載し、後の工程で修正対応
• この工程では修正禁止: テスト失敗を発見してもここでは修正しない
• テスト状態を記録し、次のステップに進む

2. 事前準備

検証コンテキストの準備を行います：

1. 追加ルールの読み込み

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

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 - テストケース定義を確認
   • docs/implements/{要件名}/{{task_id}}/{feature_name}-refactor-phase.md - Refactorフェーズの結果を確認
   • 元タスクファイル (docs/tasks/{taskfile}.md) - タスクの完了状態を確認

読み込み完了後、準備されたコンテキスト情報を基にテストケース完全性検証を開始します。

2. 実装済みテストケースの確認

• 現在のテストファイルを確認
• 実装済みテストケース数をカウント
• 各テストケースの内容を予定と照合

3. 実装状況の分析とTODO.md更新判定

以下の形式で分析結果を提供してください：

## テストケース実装状況

### 📋 TODO.md対象タスク確認
- **対象タスク**: [現在のTDD開発対象タスク名]
- **現在のステータス**: [未完了/部分完了/完了済み]
- **完了マーク要否**: [要/不要]

### 📋 予定テストケース（要件定義より）
- **総数**: [予定していた総テストケース数]
- **分類**:
  - 正常系: [数]個
  - 異常系: [数]個
  - エッジケース: [数]個
  - その他: [数]個

### ✅ 実装済みテストケース
- **総数**: [実装済み総テストケース数]
- **成功率**: [通過テスト数]/[実装テスト数] ([成功率]%)

### ❌ 未実装テストケース（[数]個）
1. **テストケース名**: [予定していたが未実装のテスト]
   - **種類**: [正常系/異常系/エッジケース]
   - **内容**: [テストの詳細内容]
   - **重要度**: [高/中/低]
   - **要件項目**: [対応する要件定義書の項目]

2. **テストケース名**: [2つ目の未実装テスト]
   ...

### 📋 要件定義書網羅性チェック
- **要件項目総数**: [要件定義書の総項目数]
- **実装済み項目**: [実装・テスト済みの項目数]
- **要件網羅率**: [実装済み]/[総数] = [網羅率]%

#### 未網羅の要件項目（[数]個）
1. **要件項目**: [未実装の要件項目名]
   - **分類**: [入力パラメータ/出力仕様/制約条件/使用例/エラーケース等]
   - **内容**: [要件の詳細内容]
   - **実装不足の理由**: [なぜ未実装なのか]
   - **対応の必要性**: [必須/推奨/任意]

2. **要件項目**: [2つ目の未網羅項目]
   ...

### 📊 実装率
- **全体実装率**: [実装数]/[予定数] = [実装率]%
- **正常系実装率**: [実装数]/[予定数] = [実装率]%
- **異常系実装率**: [実装数]/[予定数] = [実装率]%
- **エッジケース実装率**: [実装数]/[予定数] = [実装率]%

4. 判定基準

✅ 完全実装済み（自動で次ステップ）

- 既存テスト状態: すべてグリーン
- 要件網羅率: 100%（全要件項目実装・テスト済み）
- テスト成功率: 100%
- 未実装重要要件: 0個
- 品質基準: 要件定義に対する完全な充実度を達成

⚠️ 実装不足あり（追加実装必要）

- 既存テスト状態: 失敗テストあり または
- 要件網羅率: 100%未満（要件定義の項目に対する実装不足）
- 重要な要件項目が未実装・未テスト
- 要件充実度に品質リスクあり

5. 検証結果のメモファイル記録とTODO.md更新

メモファイルの統合更新

検証完了後、docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md の既存内容を整理・統合し、以下の情報に更新：

# [機能名] TDD開発完了記録

## 確認すべきドキュメント

- `docs/tasks/{taskファイルのパス}.md`
- `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md`
- `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md`

## 🎯 最終結果 ([日時])
- **実装率**: [数]% ([実装数]/[予定数]テストケース)
- **品質判定**: [合格/不合格] 
- **TODO更新**: [✅完了マーク追加/要改善]

## 💡 重要な技術学習
### 実装パターン
[今後再利用できる重要な実装手法]

### テスト設計
[効果的だったテストアプローチ]

### 品質保証
[品質確保で重要だった観点]

## ⚠️ 注意点・修正が必要な項目（該当時のみ）
[実装時の重要な注意事項や未完了項目]

### 🔧 後工程での修正対象
#### テスト失敗
- [失敗しているテストケース名]
- **失敗内容**: [具体的な失敗内容]
- **修正方針**: [推奨される修正方法]

#### 実装不足
- [未実装の機能や要件]
- **不足内容**: [具体的な不足内容]
- **対応方針**: [推奨される対応方法]

#### 品質改善
- [品質向上が必要な箇所]
- **改善内容**: [具体的な改善内容]
- **改善方針**: [推奨される改善方法]

---
*既存のメモ内容から重要な情報を統合し、重複・詳細な経過記録は削除*

統合更新ルール:

1. 重要情報保持: 既存メモの技術的学習ポイント・再利用可能パターンを統合
2. 重複削除: 類似の記録・詳細な経過は最新情報に集約
3. 簡潔化: 日付・数値などの詳細は最終結果のみ保持
4. 再利用重視: 今後の開発で参考になる情報を優先して残す
5. 関連情報重視: 仕様情報などの情報は優先して残す

元タスクファイル完了マーク自動更新

検証が完了した場合、以下の手順で元タスクファイルを自動更新：

1. 完了タスクの特定: 現在のTDD開発対象タスクを元タスクファイルから特定
2. 完了マーク追加: 該当タスクに ✅ **完了** マークを追加
3. 完了理由記載: (TDD開発完了 - [テスト数]テストケース全通過) を追記
4. サブタスク更新: 関連するサブタスクにも [x] チェックマークを追加

例：

### 1. JSONファイルパス引数処理機能 ✅ **完了** (TDD開発完了 - 15テストケース全通過)

- [x] コマンドライン引数でJSONファイルパスを受け取る機能を追加
- [x] 複数のJSONファイルパスに対応（sample/ディレクトリ全体の読み込み）
- [x] 引数バリデーション機能

6. 対応アクション

完全実装済みの場合

以下のメッセージと共に次のお勧めコマンドを表示：

✅ テストケース完全性検証: 合格
- 予定テストケース: [数]個すべて実装済み
- テスト成功率: 100%
- 品質基準: 達成

次のお勧めステップ: `/tsumiki:tdd-cycle` で次のTDDサイクルを開始します。

メモファイル記録: 検証結果をメモファイルに自動追記する。 元タスクファイル更新: 完了したタスクに✅完了マークを自動追加する。

実装不足がある場合

以下のメッセージを提供し、状況を記録する：

⚠️ テストケース実装不足を検出

未実装テストケース（[数]個）があります。
以下の内容をmemoファイルに記録しました：

[未実装テストケースのリスト]

【重要】この工程では修正を行いません。
修正が必要な内容はmemoファイルに記載され、後の工程で対応されます。

現状の記録を完了し、次のステップに進みます。

メモファイル記録: 実装不足の検証結果と修正方針をメモファイルに詳細記録する。 元タスクファイル更新: 実装不足の場合でも、部分完了したタスクがあれば適切にマークする。 修正作業禁止: この工程では一切の修正作業を行わない。

検証対象ファイル

確認すべきドキュメント

• 元タスクファイル: docs/tasks/{taskファイルのパス}.md - プロジェクト全体のタスク完了状況（完了マーク更新対象）
• docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md
• docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md

確認すべきテストファイル

• src/__tests__/*.test.ts
• src/__tests__/*.test.js

確認すべき実装ファイル

• src/*.ts
• src/*.js

Gitで変更されたファイル

• git status で変更されたファイル
• git diff --name-only で変更されたファイル

品質基準

最低品質基準

• 実装率: 80%以上
• 成功率: 100%
• 重要テスト: すべて実装
• 要件網羅性: 要件定義書の主要機能をすべて網羅
• コンパイルエラー: なし

理想品質基準

• 実装率: 100%
• 成功率: 100%
• 網羅性: 全ケース対応
• 要件完全網羅: 要件定義書の全項目を網羅

要件定義書の網羅性チェック

要件定義書（requirements.md）に記載された以下の項目が実装・テストされているかを確認：

必須チェック項目

• 入力パラメータ: 全ての必須・オプション引数の処理
• 出力仕様: 期待される出力形式・構造の実装
• 制約条件: パフォーマンス・セキュリティ・互換性要件
• 基本使用例: 想定される基本的な使用パターン
• エッジケース: 境界値・例外条件の処理
• エラーケース: 異常系の適切な処理
• 主要アルゴリズム: 機能の核となる処理ロジック

網羅性判定基準

✅ 完全網羅 (100%):
- 要件定義書の全項目が実装・テストされている
- 入力パラメータの全パターンをテスト
- 出力仕様の全形式を検証
- エラーケース・エッジケースを全て網羅

⚠️ 部分網羅 (80-99%):
- 主要機能は実装されているが一部項目が未実装
- 基本的な使用例は網羅されている
- 重要でないエラーケースの一部が未実装

❌ 不十分 (<80%):
- 要件定義書の重要な項目が未実装
- 基本的な使用例に漏れがある
- エラーハンドリングが不十分

自動遷移判定

品質判定基準

✅ 高品質（要件充実度完全達成）:
- 既存テスト状態: すべてグリーン
- 要件網羅率: 100%（要件定義書の全項目に対する完全な実装・テスト）
- テスト成功率: 100%
- 未実装重要要件: 0個
- 要件充実度: 要件定義に対する完全な充実度を達成

⚠️ 要改善（要件充実度不足）:
- 既存テスト状態: 失敗テストあり または
- 要件網羅率: 100%未満（要件定義書の項目に対する実装・テスト不足）
- 重要な要件項目が未実装・未テスト
- 要件充実度: 要件定義に対する充実度が不十分
- 追加実装による要件充実度向上が必要

使用例

# refactorフェーズ後に自動実行
/tsumiki:tdd-refactor
# ↓ 自動実行
/tsumiki:tdd-verify-complete
# ↓ 実装完全なら自動実行
/tsumiki:tdd-cycle

出力形式

実装状況に応じて以下のいずれかの形式で出力：

完全実装の場合

✅ **テストケース完全性検証: 合格**

📊 今回のタスク要件充実度:
- 対象要件項目: [数]個
- 実装・テスト済み: [数]個 / 未実装: [数]個
- 要件網羅率: 100%
- 要件充実度: 完全達成

📊 全体のテスト状況:
- 全テストケース総数: [数]個  
- 成功: [数]個 / 失敗: [数]個
- 全体テスト成功率: [数]%

🚀 要件定義に対する完全な充実度を達成しました。
自動で次のTDDサイクルに進みます。

実装不足の場合

⚠️ **テストケース実装不足を検出**

📊 今回のタスク要件充実度:
- 対象要件項目: [数]個
- 実装・テスト済み: [数]個 / 未実装: [数]個  
- 要件網羅率: [数]%
- 要件充実度: [充実度レベル]

📊 全体のテスト状況:
- 全テストケース総数: [数]個
- 成功: [数]個 / 失敗: [数]個
- 全体テスト成功率: [数]%

❌ 未実装テストケース:
[未実装テストケースの詳細リスト]

📝 **修正内容をmemoファイルに記録済み**
後の工程で対応予定です。この工程では修正を行いません。

この検証により、TDD開発の品質と完全性を確保します。