100%という数字の甘い罠
マネージャーが大好きな言葉がある。「定量的な目標」だ。そして、テストカバレッジ100%という響きほど、無能な管理職を安心させ、現場のエンジニアを絶望させる呪文はない。断言しよう。100%を目指し始めた瞬間、あなたのチームのテストコードは「品質の保証」ではなく「数字を稼ぐための作業」に成り下がる。
カバレッジは「通った」ことを示すだけで「正しい」とは言っていない
考えてもみてほしい。コードの全行を通過させるだけなら、中身のないスカスカなテストでも達成可能だ。値を検証しないアサーションなしのテストでも、カバレッジツールは満面の笑みで「100%」を返してくれる。これは、火災報知器が鳴るかどうかを確認するために、報知器のボタンを指でなぞるだけで「点検完了」と言い張るのと同じくらい愚かなことだ。
- ゲッターとセッターをテストして、何か新しい発見があったか？
- フレームワークが保証している機能を二重にテストして、給料分の仕事をしたと言えるのか？
- 条件分岐の全ルートをなぞることに執着して、肝心のビジネスロジックの矛盾を見落としていないか？
リファクタリングを阻む「テストの壁」
皮肉なことに、カバレッジに固執したコードほど、変更に弱い。実装の細部までガチガチに固めた「形だけのテスト」は、コードを少し改善しようとするたびに真っ赤なエラーを吐き出し、エンジニアの足を引っ張る。本来、テストは変更を勇気づけるための翼であるはずなのに、いつの間にか身動きを封じる鎖に変わってしまうのだ。
「安心感」という名の幻想を買うコスト
100%のカバレッジを維持するためのコストは、80%から90%にする時の比ではない。最後の数パーセントを埋めるために、エンジニアは極めて稀な例外処理や、モック化すら困難な外部依存関係と格闘することになる。その時間は、本来なら新機能の実装や、より複雑なエッジケースの検討に充てられるべきものだ。
現場を殺す「グリーン・バー」への執着
テスト結果のバーを緑に保つことが目的になると、エンジニアの創造性は死ぬ。カバレッジが下がらないようにと、意味のないテストコードを量産し、CI/CDの実行時間は無駄に伸びていく。結果として、開発サイクルは鈍化し、現場には「言われた通りに数字を埋める」だけの受動的な空気が蔓延する。これこそが、プロダクトを内側から腐らせる真犯人だ。
結論：緑のバーに魂を売るな
我々が本当に必要なのは、カバレッジツールの数字ではなく「このコードを変更しても壊れない」という確信だ。重要なビジネスロジックには厚いテストを、自明なコードには必要最小限のチェックを。その見極めこそがプロの仕事であり、ツールに依存した数字遊びではない。
もし、あなたのチームが「カバレッジ100%」を義務付けているなら、今すぐその教典をゴミ箱に捨てるべきだ。でなければ、あなたのプロダクトは、完璧にテストされた「動かないゴミ」へと進化を遂げることになるだろう。
コメント