# 品質ゲート

Pentagon（Reviewer）がテストファイルをレビューする際の判定基準。
全項目 PASS で合格、1 項目でも FAIL で差し戻し。

## 判定項目

### A. 5 分類カバレッジ

- [ ] 正常系テストが存在する
- [ ] 異常系テスト（バリデーションエラー、404 等）が存在する
- [ ] 境界値テスト（空リスト、最大長等）が存在する
- [ ] エッジケース（重複、同時更新等）が考慮されている
- [ ] 外部依存エラー時の挙動がテストされている（該当する場合）

### B. 振る舞い契約の検証

- [ ] HTTP ステータスコードが正しい
- [ ] レスポンスボディの構造が正しい（フィールド名、型）
- [ ] DB の状態変更が検証されている（POST/PUT/DELETE）
- [ ] エラーレスポンスのフォーマットが統一されている

### C. コード品質

- [ ] Given-When-Then 構造が明確
- [ ] テスト関数名が振る舞いを説明している
- [ ] テスト間に依存がない（独立して実行可能）
- [ ] 不要な assert がない（1 テスト 1 概念）
- [ ] ハードコードされたマジックナンバーがない

### D. Hermetic & Deterministic

- [ ] 各テストが独立した DB 状態を持つ（testcontainers or トランザクション）
- [ ] 外部 API は trait DI でテストダブルに差し替えている
- [ ] 時刻依存のテストは Clock trait で制御している
- [ ] テスト実行順序に依存しない
- [ ] `sleep` や固定タイムアウトに依存しない

### E. Rust 固有

- [ ] `#[tokio::test]` が正しく使われている
- [ ] `unwrap()` はテストコード内でのみ使用（本番コードに混入していない）
- [ ] `clippy` 警告がない
- [ ] `rustfmt` でフォーマット済み

## 判定フロー

```
全項目チェック
  ├─ 全 PASS → PASS（テスト承認）
  ├─ FAIL あり（修正可能）→ FAIL + 具体的な修正指示
  └─ FAIL あり（設計レベル）→ FAIL + 設計変更の提案
```

## レポートフォーマット

```
[Pentagon Review] {test_file}

判定: PASS / FAIL

A. 5分類カバレッジ: PASS / FAIL
   {不足があれば具体的に}

B. 振る舞い契約: PASS / FAIL
   {問題があれば具体的に}

C. コード品質: PASS / FAIL
   {問題があれば具体的に}

D. Hermetic: PASS / FAIL
   {問題があれば具体的に}

E. Rust 固有: PASS / FAIL
   {問題があれば具体的に}

修正指示:
  1. {具体的な修正内容}
  2. {具体的な修正内容}
```
