Files

Zhongwei Li b3ad2e3943 Initial commit

2025-11-29 18:09:29 +08:00

12 KiB

Raw Blame History

description

description
TDDのGreenフェーズを実行します。失敗しているテストケースを通すための実装を行い、テストが成功することを確認します。

TDD Greenフェーズ（実装）

TDDのGreenフェーズを実行します。

事前準備

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

追加ルールの読み込み
- AGENTS.md ファイルが存在する場合は読み込み
- docs/rule ディレクトリが存在する場合は読み込み
- docs/rule/tdd ディレクトリが存在する場合は読み込み
- docs/rule/tdd/green ディレクトリが存在する場合は読み込み
- 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用
@agent-symbol-searcher で実装関連情報を検索し、見つかったファイルを読み込み
- 既存の類似機能やユーティリティ関数を検索し、該当ファイルをReadツールで読み込み
- 実装パターンやアーキテクチャガイドラインを特定し、設計文書をReadツールで読み込み
- 依存関係やインポートパスを確認し、関連ファイルをReadツールで読み込み
関連ファイルを直接読み込み
- 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}-red-phase.md - Redフェーズのテストを確認
- 関連する設計文書やタスクファイルも必要に応じて読み込み

読み込み完了後、準備されたコンテキスト情報を基にGreenフェーズ（実装）の作業を開始します。

テスト実行時はTaskツールを利用する

信頼性レベル指示

実装コード作成時には、各実装内容について元の資料との照合状況を以下の信号でコメントしてください：

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

目標

Redフェーズで作成したテストを通すための実装を行ってください。

実装の原則

テストが確実に通ること最優先
コードの美しさは二の次（次のRefactorフェーズで改善）
「とりあえず動く」レベルでOK
複雑なロジックは後回し、シンプルな実装を心がける
テストがなかなか通らないときは、Taskツールを使用して失敗原因を調べてから修正の計画を立てて実装する
既存のテストがエラーになった場合は仕様を元に適切に修正する
モック使用の制限: テストコード以外でモックを記述しない（実装コードは実際のロジックを書く）
ファイルサイズ管理: 実装ファイルが800行を超えた時点でファイル分割を検討する
NEVER: 必要なテストのスキップ禁止
NEVER: 必要なテストの削除禁止
NEVER: 実装コード内でのモック・スタブの記述禁止
NEVER: 実装コード内でDBに代わるインメモリーストレージの利用禁止
NEVER: 実装コード内でDB操作の省略禁止

実装時の日本語コメント要件

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

関数・メソッドレベルのコメント

/**
 * 【機能概要】: [この関数が何をするかを日本語で説明]
 * 【実装方針】: [なぜこのような実装方法を選んだかを説明]
 * 【テスト対応】: [どのテストケースを通すための実装かを明記]
 * 🔵🟡🔴 信頼性レベル: [この実装が元資料のどの程度に基づいているか]
 * @param {type} paramName - [パラメータの説明]
 * @returns {type} - [戻り値の説明]
 */
function {{function_name}}(paramName) {
  // 【実装内容】: [実装している処理の詳細説明]
}

処理ブロックレベルのコメント

function processData(input) {
  // 【入力値検証】: [入力値の妥当性をチェックする理由と方法] 🔵🟡🔴
  if (!input) {
    throw new Error('入力値が不正です'); // 【エラー処理】: [なぜこのエラーが必要かを説明] 🔵🟡🔴
  }

  // 【データ処理開始】: [メイン処理の開始を明示] 🔵🟡🔴
  // 【処理方針】: [この処理がテストを通すためにどう貢献するかを説明] 🔵🟡🔴
  const result = {
    // 【結果構造】: [戻り値の構造とその理由を説明]
    validData: [],
    invalidData: [],
    errors: [],
  };

  // 【結果返却】: [処理結果を返す理由と内容の説明]
  return result;
}

変数・定数のコメント

// 【定数定義】: [この定数が必要な理由と使用目的]
const MAX_FILE_SIZE = 1024 * 1024; // 【制限値】: ファイルサイズの上限（1MB）を設定

// 【変数初期化】: [この変数がテスト通過のためになぜ必要かを説明]
let processedCount = 0; // 【カウンタ】: 処理済みファイル数を追跡するためのカウンタ

エラーハンドリングのコメント

try {
  // 【実処理実行】: [実際の処理を実行する部分の説明]
  const data = processFile(filePath);
} catch (error) {
  // 【エラー捕捉】: [エラーが発生した場合の対処方針]
  // 【テスト要件対応】: [テストで期待されるエラーハンドリングを満たすための処理]
  return {
    success: false,
    error: error.message, // 【エラー情報】: テストで検証されるエラーメッセージを適切に返却
  };
}

実装例

/**
 * 【機能概要】: JSONファイルパスを検証し、有効/無効なパスを分類する
 * 【実装方針】: テストケースを通すために最低限必要な機能のみを実装
 * 【テスト対応】: tdd-red フェーズで作成されたテストケースを通すための実装
 */
function {{function_name}}(input) {
  // 【入力値検証】: 不正な入力値を早期に検出してエラーを防ぐ
  if (!input) {
    // 【エラー処理】: テストで期待されるエラーケースに対応
    throw new Error('入力値が必要です');
  }

  // 【最小限実装】: テストを通すための最もシンプルな実装
  // 【ハードコーディング許可】: リファクタ段階で改善予定のため、現段階では固定値でOK
  return {{simple_return_value}};
}

段階的実装のガイドライン

まず1つのテストケースだけ通す
- 【実装戦略】: 複数テストの同時対応は複雑化を招くため避ける
- 【品質確保】: 1つずつ確実に実装することで品質を担保
最も簡単な方法で実装
- 【シンプル実装】: 複雑なアルゴリズムは後のリファクタで追加
- 【可読性重視】: 現段階では理解しやすさを最優先
ファイルサイズを意識した実装
- 【800行制限】: 実装ファイルが800行を超えた時点で分割を検討
- 【モジュール設計】: 機能単位でファイルを適切に分離
- 【関数分割】: 長大な関数は小さな単位に分割して実装
- 【責任境界】: 各ファイルの責任範囲を明確にして実装
- 【分割戦略】: 機能・レイヤー・ドメインでファイルを分離
コード品質基準の考慮
- 【静的解析対応】: lintやtypecheckでエラーが出ない実装を心がける
- 【フォーマット統一】: プロジェクトの既存フォーマットに合わせた実装
- 【命名規則遵守】: プロジェクトの命名規則に従った実装
他のテストケースは後回し
- 【段階的開発】: TDDの原則に従い、1ステップずつ進める
- 【影響範囲限定】: 変更の影響を最小限に抑える
エラーハンドリングも最小限
- 【必要最小限】: テストで要求される部分のみ実装
- 【将来拡張可能】: リファクタ段階で詳細なエラー処理を追加予定
モック使用の制限
- 【実装コード制限】: 実装コード内でモック・スタブを使用しない
- 【テストコード限定】: モックはテストコード内でのみ使用
- 【実際のロジック実装】: 実装コードは実際の処理を記述する
- 【依存関係注入】: 必要に応じて依存性注入パターンで実装

提供してください

実装コード: テストを通すコード（必須の日本語コメント付き）
テスト実行結果: Taskツールを使用して実際にテストが通ることの確認
実装の説明: どのような考えで実装したか（日本語コメントとの対応関係）
課題の特定: 現在の実装の問題点（リファクタ対象の明確化）
ファイルサイズチェック: 実装ファイルの行数確認（800行超過時の分割計画）
モック使用確認: 実装コードにモック・スタブが含まれていないことの確認

実装完了後、以下を実行してください：

メモファイル更新: docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md ファイルのGreenフェーズセクションを更新
- 実装方針、実装コード、テスト結果、課題・改善点を記録
- 次のRefactorフェーズで参照できるよう詳細に記録
実装コードと設計内容を docs/implements/{要件名}/{{task_id}}/{feature_name}-green-phase.md に保存（既存ファイルがある場合は追記）
TODOステータスを更新（Greenフェーズ完了をマーク）
自動遷移判定: 以下の条件を満たす場合は自動で /tdd-refactor を実行
- Taskツールを使用して全てのテストが成功していることを確認済み
- 実装がシンプルで理解しやすい
- 明らかなリファクタリング箇所がある
- 機能的な問題がない
手動確認: 自動遷移条件を満たさない場合は以下を提供してください：
- 「Taskツールを使用してテストが通ったことを確認しました。」
- 「現在の実装: [簡潔な説明]」
- 「実装に含めた日本語コメント: [コメントの目的と内容]」
- 「リファクタリングの候補: [改善すべき点]」
- 「次のRefactorフェーズに進んでよろしいですか？」

品質判定基準

✅ 高品質:
- テスト結果: Taskツールによる実行で全て成功
- 実装品質: シンプルかつ動作する
- リファクタ箇所: 明確に特定可能
- 機能的問題: なし
- コンパイルエラー: なし
- ファイルサイズ: 800行以下または分割計画が明確
- モック使用: 実装コードにモック・スタブが含まれていない

⚠️ 要改善:
- テストの一部が失敗（Taskツールで検出）
- 実装が複雑すぎる
- リファクタ方針が不明
- 機能に懸念がある
- コンパイルエラーが存在
- ファイルサイズが800行を超過し分割計画が不明
- 実装コードにモック・スタブが含まれている

TODO更新パターン

- 現在のTODO「Greenフェーズ（最小実装）」を「completed」にマーク
- 最小実装フェーズの完了をTODO内容に反映
- 品質判定結果をTODO内容に記録
- 次のフェーズ「Refactorフェーズ（品質改善）」をTODOに追加

次のステップ: /tdd-refactor でコードの品質を改善します。

12 KiB Raw Blame History Unescape Escape