code-test

name	code-test
description	テストケース設計、回帰テスト追加、テストコードレビュー、テスト戦略の整理を行うときに使う。正常系、異常系、境界値、データ整合性、互換性、性能、flake、モック方針を検討し、変更に対する安心感を高めつつ維持コストを抑える。

testing.md（テスト観点・テスト設計）

目的：変更に対する安心感を最大化しつつ、テストの維持コストを最小化する。 テストは「実装の正しさ」を示すだけでなく、「将来の変更で壊れない」ことを保証する観測手段である。

---

基本姿勢（Core Mindset）

• テストは「何を保証するか」を明確にするためのもの（実装の写しではない）
• 重要なのはカバレッジではなく、壊れやすい領域が観測できているか
• テストは最終的に 開発速度を上げる ために存在する（遅くするなら設計を疑う）

テストの分類（何をどこで担保するか）

Unit（ユニットテスト）

• 小さな関数/ロジックの振る舞いを保証する
• 依存（DB/外部API/ネットワーク）は原則排除
• ドメインルール、境界値、純粋ロジックに強い

Integration（統合テスト）

• I/O を含む複数コンポーネントの連携を保証する
• DB・キュー・キャッシュ・外部APIクライアントなどの接続を含む
• マイグレーションやクエリの妥当性、トランザクション、整合性に強い

E2E（エンドツーエンド）

• ユーザー視点のシナリオを保証する
• 破壊的変更や回帰に強いが、遅い・不安定になりやすい
• 「最小本数」で重要フローのみ担保する

---

テスト観点（何を見るべきか）

1. 正常系（Happy path）

• 想定通りの入力で、期待する結果が得られるか
• 主要な分岐（代表値）が最低限カバーされているか

2. 境界値（Boundary）

• 空、最小、最大（長さ/桁/件数/金額/日付範囲など）
• 上限/下限を超えたときの扱い
• 並び順やページング（0件、1件、境界ページ）

3. 異常系（Failure modes）

• バリデーションエラー
• 認証/認可エラー（権限不足・他人のリソース）
• 外部依存の失敗（タイムアウト、5xx、ネットワーク）
• DB 失敗（制約違反、deadlock、接続断）

4. データ整合性（Data integrity）

• 冪等性（リトライ/重複で二重登録しない）
• トランザクション（部分成功を残さない）
• 競合更新（lost update を防ぐ）

5. 互換性・回帰（Regression）

• 既存の挙動が壊れていないか（特に公開API/契約）
• 破壊的変更の検知（レスポンス構造、ステータスコード、エラー形式）

6. 可観測性（Observability）

• 失敗時に必要な情報が残るか（ログ/メトリクス/トレース）
• エラーが握りつぶされていないか