レビューで「テストがある」ことと「テストが退行を検知できる」ことは別物。次のパターンは対象の挙動を壊しても通り続ける空通し(vacuously passing)になりやすく、重点的に疑う。

疑うパターン

• 例外を投げないことだけを確認する no-throw テスト
• 実装の出力をそのまま写したアサーション(実装が壊れても一緒に壊れ、回帰を捕まえない)
• 入力は多要素なのにアサーションが一部しか検証しない(例: 複数フィルタを渡すのにハンドラのテストが1項目しか assert しない。どれかが欠落しても通る)
• 期待値が「空」や「デフォルト」に固定されている(フィルタが実際に伝播しなくても検知できない)
• 順序・並べ替えロジックに対しテストデータが1件しかない/すでにソート済み(並べ替えを削除・破損しても通る)
• 正例・負例を別々に持つが、両者が同時成立する交差条件を突いていない

検証の勘所

• 境界(ハンドラ→ユースケース→リポジトリ)を跨ぐ配線の退行は、下層に直接値を渡す統合テストでは捕まらない。入力を変化させ、その差が出力や呼び出し引数に現れることを確認するテストが要る
• 「この振る舞いを削除したらどのテストが落ちるか」を自問し、落ちるテストが無ければ空通し。分類・判定ロジックを変えたら「誤分類が起きる具体的入力」を1ケース足させる