第33回：【テストコードのガイドライン その8】【数字】カバレッジ100%の幻想 ── 網羅率という「数字」に魂を売るな。

♨️ ヒマリの「完全勝利」宣言

東根温泉支部の開発室。窓の外では、春の夜風に運ばれた硫黄の香りが、咲き始めたさくらんぼの花の香りと混ざり合い、この地ならではの独特な季節の訪れを告げている。しかし、今日のヒマリにとって、そんな情緒に浸る暇はなかった。

プロジェクトもいよいよ大詰め。ヒマリはここ数週間、食事の時間も惜しんでテストコードの「完成度」を高めることに全神経を注いできた。そして今、彼女のモニターには、まばゆいばかりの、そして残酷なまでに完璧な数字が表示されていた。

ヒマリ： 「……できた。ついに、辿り着いた……！」

ヒマリは椅子を蹴り飛ばさんばかりの勢いで立ち上がり、ラウンジで新作のスイーツを試食していたサキのもとに駆け寄った。

ヒマリ： 「サキ先輩！ サキ先輩！ 見てください、これ！ ついにやりました……カバレッジ100%ですッ！！」

ヒマリが突き出したノートPCの画面には、すべてのソースファイルが「緑色」に染まり、網羅率を示す数値が誇らしげに「100.0%」と刻まれていた。

ヒマリ： 「全ての行、全ての分岐、全ての条件式をテストが通過しました！ 一行の漏れもありません。マリさんに教わった通り、これでこのシステムにバグが入り込む隙間は1ミリも存在しません！ 私たちの勝ちです！」

サキ： 「おー、100%？ マジ？ 数字だけ見ると、歴史に残るレベルの完璧じゃん。✨」

サキはフォークを置き、感心したように目を細めた。しかし、彼女の視線がヒマリの誇る「100%のコード」の細部に移った瞬間、その瞳にわずかな、しかし鋭い懸念が宿った。

サキ： 「……でもさ、ひま。なんかこのコード……全体的に妙に『膨らんで』ない？✨」

♨️ 数字を追うために「歪んだ」コードの断末魔

サキはヒマリの隣に座り、いくつかのファイルをランダムに開いていった。そこに並んでいたのは、かつてのヒマリが大切にしていた「シンプルで美しい設計」とは程遠い、歪なコードの群れだった。

サキ： 「ねぇ、ひま。この else 句のブロック……これ、本番の運用では絶対にあり得ない状況だよね？✨」

サキが指差したのは、ある例外処理の分岐だった。通常では絶対に発生しないシステム内部の矛盾を拾うための分岐だが、その中を通すためだけに、プロダクションコード側に「テスト時のみ無理やり例外を発生させるためのフラグ」が追加されていた。

ヒマリ： 「あ……。そこは、カバレッジを通すのが難しくて。どうしても赤色が残っちゃうのが許せなかったんです。だから、テストコードから特定の値を送った時だけ、無理やりその例外ルートを通るようにロジックを微調整しました。……でも、これで100%になったんですよ！」

ヒマリの弁明は続く。 「こっちのゲッターとセッターも、フレームワークが自動生成するものだけど、カバレッジを下げる原因になるから全部テストを書きました。あと、この複雑な if 文も、リファクタリングして消しちゃうとテストケースが減ってカバレッジ計算が狂いそうだったから、あえてそのまま残して全パターン網羅したんです！」

100%という数字を叩き出すために、ヒマリはリファクタリング（設計の改善）を諦め、カバレッジを通すためだけの「不自然なコード」を書き足し、本来テスト不要な場所にまで膨大な労力を注ぎ込んでいた。

♨️ 100%を目指すと「本質」が死ぬ ── 数字への埋没

サキ： 「（深いため息をついて、モニターを指差す）……ひま。数字に魂を売っちゃダメ！✨ 100%にするためにプロダクトコードを歪ませるなんて、本末転倒もいいところだよ！✨」

サキの言葉は、温泉の源泉のように熱く、ヒマリの胸に突き刺さった。

サキ： 「カバレッジっていうのはね、『どこをテストしていないか』を可視化するための目安であって、それを100にすることがゴールじゃないんだよ。✨」

サキはホワイトボードに向かい、大きな「100%」という文字に×印を書いた。

サキ： 「数字に執着すると、二つの致命的な『死』を招くんだよ。✨」

① 保守コストの爆増（ゴミテストの量産）

フレームワークの機能や、単なる値の受け渡し。そんな「テストしなくても壊れない場所」にまで無理やりテストを書けば、コードを変更するたびに大量の無意味なテストが壊れる。それは『盾』じゃなくて、開発者の足を引っ張る『おもり』だよ。

② 安心という名の錯覚

ここが一番怖いんだけど、『行を通った』ことと『正しく検証した』ことは、全く別物なんだよ。✨ アサーション（検証）がザルでも、その行を通過さえすればカバレッジは上がる。100%という数字に安心しきって、肝心の「境界値でどう動くか」という深い検証を忘れたら、その100%はただの『張りぼて』でしかないんだよ。

ヒマリは呆然と立ち尽くした。自分が心血を注いできた「緑色に染まった世界」が、実は設計の純度を汚し、自分自身の首を絞める罠だったことに気づかされたのだ。

♨️ 大事なのは「網羅率」より「納得感」

騒ぎを聞きつけたマリが、静かに琥珀色のお茶を二人に差し出した。

マリ： 「ヒマリちゃん。プロの現場ではね、カバレッジは80%から90%程度あれば十分だと言われているわ。☕」

ヒマリ： 「えっ……！？ 100じゃなくていいんですか？ 残りの10%を放置するのは、プロとして無責任なんじゃ……。」

マリ： 「いいえ。その残りの10%……例えば、どうしても再現が困難なインフラ層の例外処理や、フレームワーク内部の挙動。それらを無理やり網羅するために、無理な設計を強いたり、不自然なフラグを立てたりするのは、それこそがプロとして無責任な行為なの。☕」

マリはヒマリの肩に優しく手を置いた。

マリ： 「大事なのは数字の大きさじゃない。『自分たちが守るべき急所（ビジネスロジックや境界値）が、正しく検証されているか』という納得感なのよ。☕」

ユイ： 「あぅ……っ。……数字を100にすることより……。壊れたら一番困る場所を、絶対に逃さないように守るほうが……ずっと『盾』として強いんだねぇ……っ。……数字は、私たちを安心させてくれるけど……本当の安心は、自分のコードへの『信頼』の中にあるんだね……っ。」

ユイの澄んだ言葉が、ヒマリの頑なだった心を溶かしていった。 100%という完璧な数字の裏で、自分がいかに「思考」を停止させ、ただ数字を埋めるだけの作業に逃げていたか。

ヒマリ： 「……わかりました。私、100%という呪縛から卒業します。数字に踊らされて設計を汚すのは、もうやめます。これからは、たとえ数字が85%になっても、その85%の中に『絶対に壊さない』という確信を詰め込んでいきます！」

ヒマリは再びデスクに向かい、カバレッジを稼ぐためだけに追加した「不純なコード」を一つずつ削除し始めた。 網羅率のバーは少しずつ下がっていく。しかし、それと引き換えに、コードは本来のしなやかさと美しさを取り戻していった。

東根温泉の夜。琥珀色の湯から立ち上る湯気は、決して一つの形に固まることはない。しかし、そのゆらぎの中にこそ、本物の癒やしと力がある。 ヒマリが手にしたのは、数字という名の虚像ではなく、自身の設計思想に基づいた、確かな手応えのある「納得感」という名の盾だった。

📜 ボスの秘蔵：設計の美学と現場のリアル

カバレッジ100%という数字。 それを達成するために、以下のようなプロダクトコードとテストコードを書いたとしましょう。

def meaningless_process(x):  
    result = 0
    if x > 0:
        result = x * 2
    elif x < 0:
        result = x - 5
    else:
        result = 0
    
    status = "completed" 
    return result

仮の実装と思ってください。(本番でこういう実装はないと思います。)

# 期待値の検証（アサーション）を一切行わず、
# ただ「全行を通過させる」ためだけにメソッドを呼び出すテスト
def test_meaningless_coverage(self):
    meaningless_process(10)  # ifを通す
    meaningless_process(-1)  # elifを通す
    meaningless_process(0)   # elseを通す

# 「エラーが起きなかったこと」だけを確認するテスト
def test_useless_assertion(self):
    result = meaningless_process(100)
    self.assertIsNotNone(result) # 中身が間違っていてもパスする

どうでしょうか。このテストに、果たして「意味」はあるでしょうか。

PHPであれPythonであれ、カバレッジ100%を「目的」にした瞬間、テストは牙を剥きます。アサーション（検証）をまともに書かず、単にメソッドを叩いてエラーが起きなかったという事実だけで網羅率を稼ぐ。そんな「中身のないテスト」が、現場には溢れています。

さらに恐ろしいのは、その100%という数字を維持するために、本来不要なコードを実装したり、DBや外部サービスにアクセスしなくていい場面で無理やりアクセスさせたりと、「無意味なコスト」が増大していくことです。

100%という数字自体が悪いのではありません。 「100%にするために無駄なコードを増やす」という、手段と目的の履き違えが問題なのです。

特に、昨今のAIにテストコードを書かせる際はこの傾向が顕著です。AIは往々にして「メソッドがエラーなく完遂すること」でカバレッジを稼ごうとします。その結果、人間がビジネスロジックを修正して計算結果が変わってしまったとしても、テストコード上はエラーが起きず、そのままスルーされてしまう。そして、バグは本番運用が始まってから、最悪のタイミングで牙を剥くことになります。

結局、「AIに任せるとテストの品質が担保できない」という結論になりがちですが、それは裏を返せば「ユーザー（人間）が、意味のあるテストとは何かを理解した上で指示を出しているか？」という問いに直結します。

意味のあるテストを、意味のある労力で書く。 そのためには、テスト対象が「何を検証すべきか」が明確で、外部依存が適切に切り離された「良い設計」が不可欠です。

数字に魂を売る前に、もう一度自分の設計を見直してみませんか？ 設計こそが、無意味な100%からあなたを救い出し、真に価値のある「盾」を授けてくれるのです。

（つづく）

#エンジニア #プログラミング #テストコード #ユニットテスト #カバレッジ #網羅率 #ソフトウェア開発 #設計 #品質保証 #QA #リファクタリング #クリーンコード #技術的負債 #エンジニアの成長 #東根温泉秘密結社 #納得感 #ビジネスロジック