テスト戦略のアンチパターン ── ここまでを裏側からまとめる

各項目は「何を誤解しているか」と「どう戻すか」の形で書きます。責める意図はありません。いずれももっともらしい理由があって発生するものだからです。

症状: テストカバレッジ（Test Coverage） の目標値が設定され、達成のためにテストが書かれる。数値は上がるが、不具合の流出は減らない。

誤解: 通過した行の割合が、品質と相関すると考えていること。実際には、アサーション（Assertion） が空でも数値は上がります。低いカバレッジは問題を示しますが、高いカバレッジは何も保証しません。

戻し方: 数値を捨てる必要はありません。重要な経路が守られているかという別の観点を併置します。ミューテーションテスト（Mutation Testing） を重要な経路にだけかけると、「通っているが検証していない」箇所が具体的に出てきます。

症状: テストは全部通っているのに、本番で壊れる。調べると、スナップショットテスト（Snapshot Test） が無確認で更新されていた、モック（Mock） が本物と乖離していた、といった原因が出てくる。

誤解: 「通っている」を「検証されている」と同一視していること。EP.6 で扱ったとおり、この2つは別です。

戻し方: 記録ファイルをレビュー対象に含める。モックが本物と乖離していないかを、契約として確認する層を1つ置く。どちらも仕組みの問題なので、気をつけるでは解決しません。

症状: E2Eテスト（End-to-End Test） が数百本あり、実行に長時間かかる。失敗しても原因が分からず、再実行が常態化している。

誤解: 本番に近いほど良いテストだ、という考え方。近さと引き換えに、速度・安定性・原因の特定しやすさを失っています。しかも失ったものは、日々の開発速度に効きます。

戻し方: EP.4 の定義に戻り、E2E の役割を配線の確認に絞る。ロジックの検証は下の層へ降ろす。降ろす作業自体は、いまは高速に進められます。

症状: 赤が出たらまず再実行する。通れば次へ進む。この流れが定着している。

誤解: 不安定さの被害を、そのテスト単体で見積もっていること。EP.11 で書いたとおり、実際の被害は赤に対する反応の変化として全体に及びます。

戻し方: 再実行を禁止するのではなく、再実行したことを記録する。何回目で通ったかが見えれば、不安定さは可視化されます。そのうえで、隔離には期限と担当を付ける。

症状: リファクタリングのたびに大量のテストが落ちる。振る舞いは変わっていないのに直す作業が発生する。

誤解: テストは細かく分離するほど良い、という前提。分離のために モック を挟むと、テストが内部構造を知っている状態になります。内部構造は変わってよいものなので、変えるたびに壊れます。

戻し方: EP.2 の基準に戻り、モックは外部との境界にだけ置く。内部は スタブ（Stub） で足ります。単位は関数ではなく観測できる振る舞いで取り直す。

症状: 手元でテストを流さなくなり、CI（Continuous Integration） 任せになっている。結果を待つ間に別の作業へ移り、戻ってくる頃には文脈を失っている。

誤解: 速度を快適さの問題と捉えていること。実際には、遅いテストは使われなくなるという機能の問題です。

戻し方: EP.3 の順序（計測 → 原因特定 → 削減 → 分割 → 並列化）で進める。まず上位の数本を潰すだけで体感が変わることが多い。並列化から入らないこと。

症状: LLM の出力をスナップショットで固定し、毎回落ちる。結果として、そのテストが無効化される。

誤解: すべての出力は決定的であるべきだ、という前提。非決定性（Non-determinism） が前提の対象に、決定的な検証を当てても機能しません。

戻し方: EP.7 の3層（形式・制約・内容）に分解する。上2層は決定的に判定できます。内容は合否ではなく、前回との比較で見る。

症状: 評価の仕組みを検討して数週間が経つが、まだ1件も評価していない。網羅性と代表性の議論が続いている。

誤解: 評価は統計的に厳密でなければ意味がない、という前提。変更前後の比較という目的なら、少数でも機能します。

戻し方: EP.8 のとおり、30件で回し始める。失敗した事例が次の30件の材料になります。厳密さは、使い始めてから必要に応じて足せます。

症状: コスト削減の名目で、テストの一部が定期実行へ移され、失敗しても続行する設定が入る。費用は下がったが、不具合の流出が増えた。

誤解: 費用は数字で見えるが、失われた検知力は数字にならないという非対称を考慮していないこと。比較が成立していません。

戻し方: EP.10 の順序で、副作用のない削減から先に行う。打ち切り・上限・キャッシュだけで相当削れます。削る議論では、何を検知できなくなるかを必ず併記する。

症状: 意図の読めないテストが残っている。不自然な入力値が並んでいるが理由が分からず、邪魔なので削除される。しばらくして同じ不具合が再発する。

誤解: テストコードは自己説明的である、という前提。なぜその入力なのかは、コードからは読み取れません。特に「過去に壊れたから」という理由は、書かなければ必ず失われます。

戻し方: 入力のそばにいつ何が起きたかを1行残す。テストは仕様書ではありませんが、判断の記録としては十分に機能します。

10個を並べましたが、全部を一度に直す必要はありません。検知力が落ちている項目から扱うのが原則です。優先度を付けるなら次の順になります。

1. 1緑のまま壊れる構造（2番） — 気づけない状態が最も危険
2. 2不安定の放置（4番） — 全体の信用に波及する
3. 3遅さ（6番） — 使われなくなると他の対策も効かない
4. 4E2E偏重（3番） — 上の3つの原因になっていることが多い
5. 5残り — 上4つが片付いてから

上から3つは、いずれもテストが機能しなくなる類の問題です。残りは効率や保守性の問題なので、機能を回復させてから取り組んでも遅くありません。

テストの目的は、変更を安全にすること。安全でなくなっている状態から順に直せば、優先順位で迷うことはない。