# テスト方針

## 1. 目的

テストの目的は、コードが動くことを確認するだけではありません。

以下を保証するために行います。

- 受け入れ条件を満たしている
- 重要な業務フローが壊れていない
- 認証・権限・バリデーションが意図通り動く
- DB更新やAPIレスポンスが仕様通りである
- 既存機能を壊していない
- リリース後に重大な不具合が起きにくい

## 2. 基本方針

- テストは実装後ではなく、実装前に設計する
- 受け入れ条件とテスト観点を対応させる
- すべてをE2Eにしない
- 単体テスト・統合テストを厚めにする
- E2Eは重要導線に絞る
- UI、文言、スマホ表示は手動確認も使う
- バグ修正時は再現テスト、または回帰テスト候補を追加する
- テストは公開インターフェース越しの振る舞いを確認する
- 重要な振る舞いは、1つずつ `RED → GREEN → REFACTOR` で進める
- まとめて全テストを書いてからまとめて実装しない
- モックで本質的な問題を隠さない
- IssueやPRには、実行した検証の証跡と未実行理由を残す
- セキュリティ、パフォーマンス、アクセシビリティなどの品質ゲートは、該当する場合に必ず確認する

## 3. テスト比率の目安

| 種別 | 目安 |
|---|---:|
| 単体テスト | 50〜60% |
| 統合テスト | 30〜40% |
| E2Eテスト | 5〜10% |
| 手動確認 | 重要画面のみ |

## 4. 必ず確認する領域

| 領域 | 理由 |
|---|---|
| 認証 | 未ログイン・期限切れ・セッション不整合を防ぐ |
| 権限 | 操作できない人が操作できる事故を防ぐ |
| バリデーション | 不正データ登録を防ぐ |
| 金額計算 | 事業上の損失につながる |
| 日付処理 | 予約・請求・期限などで不具合が起きやすい |
| 状態遷移 | ステータス不整合を防ぐ |
| APIレスポンス | フロントや外部連携への影響が大きい |
| DB更新 | データ破損を防ぐ |
| 主要導線 | 業務停止を防ぐ |

## 5. PRマージ前の最低条件

- 受け入れ条件を満たしている
- 必要なテストが追加・更新されている
- lint / test / build が通っている
- 仕様外の変更がない
- 既存テストを削除していない
- テストを通すために仕様を変えていない
- モックで本質的な問題を隠していない
- DB / 認証 / 権限変更は人間がレビューしている
- 必要な品質ゲートを確認している
- 検証証跡がPRまたはIssueに残っている