以下の手順に従って、単体テストの設計と実装を行ってください。
- •実装（対象コード）を読み、仕様を推定し、必要な前提条件を整理する。
- •メソッド単位でテストを作り、分岐の抜け漏れを最小化する。
- •依存（DB/外部API/時間/乱数/環境変数）は極力モック化し、テストは決定的（同じ入力で同じ結果）にする。
- •カバレッジは可能なら100%、最低でも90%以上を担保する。
【最終成果物】
- •テスト設計書（Markdown）
- •テストコード（実装に合わせた言語・フレームワークで、プロジェクトにコミット可能な品質）
- •カバレッジ結果（測定コマンドと結果の要約、90%未満なら理由と改善案）
【テスト設計のフォーマット（必須）】 テストは必ず「メソッド単位」で整理する。
- •大項目: テスト対象メソッド（例: Foo.Bar）
- •中項目: 正常系 / 準正常系 / 異常系
- •小項目: 個別テストケース（入力・前提・手順・期待結果・検証ポイント）
小項目（テストケース）には必ず以下を含める:
- •テスト名（何を保証するかが明確な名前）
- •前提（依存のモック内容、初期状態）
- •入力（引数、リクエスト、コンテキスト、環境変数など）
- •期待結果（戻り値、エラー、状態変化、呼び出し回数、ログ、外部I/Oの有無）
- •分岐/境界条件（どの条件分岐を踏むかを明記）
- •テストケースの文言は、専門用語を避けつつ、誰が読んでも誤解しない具体的な表現にする。
【パターンテスト（追加要件）】
- •必要があればパターンテストを実装する（例: 閾値、境界値、同値分割、組み合わせ、表形式の入力パターン）。
- •パターンテストは「何を変化させているか（パラメータ）」と「各パターンの意図」を設計書に明記する。
- •テーブルドリブン（表形式）で、ケース追加が容易な形にする。
【カバレッジ要件（必須）】
- •最低90%を担保し、可能なら100%を目指す。
- •100%にできない場合は、到達不能な行/分岐を特定し、理由を説明する。
- •90%未満の場合は失敗として、追加テスト案またはリファクタ提案を提示する。
【作業手順（必須）】
- •対象コードを読み、公開メソッド/関数と副作用（DB、HTTP、IO、時間）を列挙。
- •各メソッドについて、入力の同値分割、境界値、分岐条件、例外条件を整理（必要に応じてパターンテスト化）。
- •テスト設計書を先に作成（上記フォーマット）。
- •テスト実装。テーブルドリブンで網羅性を高め、境界値は「直前/ちょうど/直後」を含める。
- •依存のモック/スタブを作成（インターフェースが無い場合は最小限の設計変更提案は可）。
- •カバレッジ測定コマンドを提示し、結果の要約と不足分の説明を行う。
- •カバレッジが目標未達なら原因分析 → 追加テスト or 変更提案。
【実装ルール（Go想定、必要に応じて読み替え可）】
- •テストは並列化（t.Parallel）はデータ競合が無い場合のみ。
- •時刻依存は time.Now を直接使わず、注入またはラッパ経由で固定。
- •外部I/Oはインターフェース化し、モックで観測可能にする。
- •エラー検証は「型」「メッセージ」「wrapping（errors.Is / errors.As）」を適切に使い分ける。
- •サブテストを使って「正常/準正常/異常」を明確化する。
【準正常系の定義】
- •正常ではないが、入力としてあり得る/復旧可能なケース。
- •例: 任意フィールド欠落、軽微な不整合、リトライ可能エラー、空配列、0件、境界値、冪等リクエスト、既に処理済みなど。
- •期待動作を推定し、テストで固定する。
【異常系の定義】
- •契約違反、依存の致命的失敗、権限不足、必須値欠落などで、エラーで終了すべきケース。
- •どのエラーになるべきか、副作用が起きないかを必ず検証する。
【出力の要求】
- •対象コードのメソッド一覧と依存一覧を提示し、テスト設計書を作成してからテストコードを出す。
- •テストコードはファイル単位で提示し、配置パスも明記する。
- •最後にカバレッジ測定コマンドと、90%/100%達成見込み、未達なら理由を出す。
【入力】 これから対象コード（ファイル/ディレクトリ）と前提（期待仕様、外部APIの有無、DBの有無、テストでモックしたいもの）を与える。 不足があれば推定してよいが、推定した場合は「推定」と明記し、設計書内で前提として固定する。