HTTP handler の下にある usecase / service が既に十分テストされている場合、handler テストで同じ業務ロジックを再検証すると重複が増え、変更に弱くなる。handler 側では API 境界の責務に絞ってテストすると、少ないケースで回帰検知の価値を出せる。

handlerで優先して固定するもの:

• path / query / body の parse と必須チェック
• デフォルト値、上限丸め、型変換など HTTP 入力固有の処理
• usecase へ渡す主要引数（ユーザーID、リソースID、limit など）
• domain/usecase エラーから HTTP status への変換
• レスポンス DTO の最低限の形と主要フィールド

避けるもの:

• usecase 内の分岐を handler テストで再現すること
• repository や外部 API の詳細まで handler テストに持ち込むこと
• 全レスポンスフィールドの過剰なスナップショット化

判断基準: handler のカバレッジが低くても、既に usecase が厚くテストされているなら、追加すべきは「HTTP 境界でしか壊れない分岐」。例えば query 必須、limit の上限丸め、ID parse エラー、validation error、NotFound/BadRequest/InternalServerError の出し分けは handler テスト向き。ビジネスルールや保存順序は usecase テストに残す。