テストエラーを解消するための自動デバッグプロセス。全テストケースの確認からエラー原因の調査、修正まで段階的に実行し、テストケースの成功率向上を目指します。
Automates debugging to resolve test errors by investigating causes and incrementally implementing fixes.
/plugin marketplace add classmethod/tsumiki/plugin install tsumiki@tsumikiテストエラーを解消して。 #ultrathink
NEVER: テストのスキップ NEVER: 既存テストケースの削除
<green_task>
エラー解消を実行します。
開発コンテキストの準備を行います：
追加ルールの読み込み
AGENTS.md ファイルが存在する場合は読み込みdocs/rule ディレクトリが存在する場合は読み込みdocs/rule/tdd ディレクトリが存在する場合は読み込みdocs/rule/tdd/green ディレクトリが存在する場合は読み込み@agent-symbol-searcher で実装関連情報を検索し、見つかったファイルを読み込み
読み込み完了後、準備されたコンテキスト情報を基にGreen task（実装）の作業を開始します。
テスト実行時はTaskツールを利用する
実装コード作成時には、各実装内容について元の資料との照合状況を以下の信号でコメントしてください：
実装コードには以下の日本語コメントを必ず含めてください：
/**
* 【機能概要】: [この関数が何をするかを日本語で説明]
* 【実装方針】: [なぜこのような実装方法を選んだかを説明]
* 【テスト対応】: [どのテストケースを通すための実装かを明記]
* 🔵🟡🔴 信頼性レベル: [この実装が元資料のどの程度に基づいているか]
* @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}};
}
実装完了後、以下を実行してください：
✅ 高品質:
- テスト結果: Taskツールによる実行で全て成功
- 実装品質: シンプルかつ動作する
- リファクタ箇所: 明確に特定可能
- 機能的問題: なし
- コンパイルエラー: なし
- ファイルサイズ: 800行以下または分割計画が明確
- モック使用: 実装コードにモック・スタブが含まれていない
⚠️ 要改善:
- テストの一部が失敗（Taskツールで検出）
- 実装が複雑すぎる
- リファクタ方針が不明
- 機能に懸念がある
- コンパイルエラーが存在
- ファイルサイズが800行を超過し分割計画が不明
- 実装コードにモック・スタブが含まれている
</green_task>
TDDのRefactorフェーズを実行します。
開発コンテキストの準備を行います：
追加ルールの読み込み
AGENTS.md ファイルが存在する場合は読み込みdocs/rule ディレクトリが存在する場合は読み込みdocs/rule/tdd ディレクトリが存在する場合は読み込みdocs/rule/tdd/refactor ディレクトリが存在する場合は読み込み@agent-symbol-searcher でリファクタリング関連情報を検索し、見つかったファイルを読み込み
関連ファイルを直接読み込み
読み込み完了後、準備されたコンテキスト情報を基にRefactorフェーズ（コード改善）の作業を開始します。
リファクタリング時には、各改善内容について元の資料との照合状況を以下の信号でコメントしてください：
Greenフェーズで実装されたコードを以下の観点で改善してください。テストは必ず通り続けることが大前提です。
単一責任原則の適用
依存関係の整理
モジュール化の検討
NEVER: 実装コード内でのモック・スタブの記述
NEVER: 実装コード内でDBに代わるインメモリーストレージの利用
リファクタリングでは既存の日本語コメントを改善し、新たなコメントを追加してください：
/**
* 【機能概要】: [リファクタ後の機能の詳細説明]
* 【改善内容】: [どのような改善を行ったかを説明]
* 【設計方針】: [なぜこの設計にしたかの理由]
* 【パフォーマンス】: [性能面での考慮事項]
* 【保守性】: [メンテナンスしやすくするための工夫]
* 🔵🟡🔴 信頼性レベル: [この改善が元資料のどの程度に基づいているか]
* @param {type} paramName - [パラメータの詳細説明と制約]
* @returns {type} - [戻り値の詳細説明と保証事項]
*/
function improvedFunction(paramName) {
// 【実装詳細】: [改善された実装の内容と理由]
}
/**
* 【ヘルパー関数】: [この関数の役割と作成理由]
* 【再利用性】: [どのような場面で再利用できるか]
* 【単一責任】: [この関数が担当する責任の範囲]
*/
function helperFunction(input) {
// 【処理効率化】: [処理を効率化するための工夫] 🔵🟡🔴
// 【可読性向上】: [コードの読みやすさを向上させる仕組み] 🔵🟡🔴
}
// 【設定定数】: [この定数の役割と設定理由] 🔵🟡🔴
// 【調整可能性】: [将来的に調整が必要になる可能性と方法] 🔵🟡🔴
const IMPROVED_CONSTANT = 100; // 【最適化済み】: パフォーマンステストに基づき最適化 🔵🟡🔴
// 【設定オブジェクト】: [設定をまとめた理由と管理方針]
const CONFIG = {
// 【各設定項目】: [それぞれの設定値の意味と影響範囲]
maxRetries: 3, // 【リトライ回数】: 実運用での経験に基づく適切な回数
timeout: 5000, // 【タイムアウト】: ユーザビリティを考慮した時間設定
};
try {
// 【安全な処理実行】: [例外が発生する可能性と対策]
const result = riskyOperation();
} catch (error) {
// 【詳細エラー処理】: [エラーの種類に応じた適切な処理]
// 【ユーザビリティ】: [ユーザーにとって分かりやすいエラー対応]
if (error.code === 'SPECIFIC_ERROR') {
// 【特定エラー対応】: [このエラーに特化した処理の理由]
return handleSpecificError(error);
}
// 【一般エラー対応】: [予期しないエラーへの安全な対処]
return handleGenericError(error);
}
describe.skip, it.skip, test.skip等でテストが無効化されていないかチェックjest.config.jsやpackage.jsonのtestPathIgnorePatterns等でテストファイルが除外されていないかチェックdebug-*.js, debug-*.ts: デバッグ用スクリプトtest-*.js, test-*.ts, temp-*.js: 一時テストファイル*.tmp, *.temp, *.bak, *.orig: 一時・バックアップファイル*~, .DS_Store: エディタ・システム生成ファイルtest-output-*, *.test-output: テスト出力ファイルfind . -name "debug-*" -o -name "test-*" -o -name "temp-*" -o -name "*.tmp" -o -name "*.temp" -o -name "*.bak" -o -name "*.orig" -o -name "*~" -o -name ".DS_Store" | grep -v node_modules でファイル検出// Before: ハードコーディング
function add(a, b) {
return 5; // とりあえず動く実装
}
// After: 適切な実装（改善された日本語コメント付き）
/**
* 【機能概要】: 2つの数値を加算し、結果を返す
* 【改善内容】: ハードコーディングを削除し、実際の加算処理を実装
* 【設計方針】: 入力値検証と型安全性を重視した設計
* 【エラー処理】: 不正な入力に対する適切な例外処理を実装
*/
function add(firstNumber, secondNumber) {
// 【入力値検証】: 数値以外の入力を早期に検出してエラーを防ぐ
// 【型安全性】: TypeScriptの型チェックと併せて実行時検証を実施
if (typeof firstNumber !== 'number' || typeof secondNumber !== 'number') {
// 【ユーザビリティ】: 開発者にとって分かりやすいエラーメッセージを提供
throw new Error('引数は数値である必要があります');
}
// 【メイン処理】: シンプルで確実な加算処理
// 【パフォーマンス】: 不要な処理を避けた効率的な実装
return firstNumber + secondNumber;
}
リファクタリング完了後、以下を実行してください：
✅ 高品質:
- テスト結果: Taskツールによる実行で全て継続成功
- セキュリティ: 重大な脆弱性なし
- パフォーマンス: 重大な性能課題なし
- リファクタ品質: 目標達成
- コード品質: 適切なレベル
- ドキュメント: 完成
⚠️ 要改善:
- テストの一部失敗（Taskツールで検出）
- セキュリティ脆弱性発見
- パフォーマンス課題発見
- リファクタ目標未達成
- 品質改善不十分
- ドキュメント不備
</refactor_task>