テスト指針：カバレッジ分析は「テストしてないコードを見つける」だけに過ぎず、それ以上の意味はない

上記記事にも記載されていることだが、自分なりの言葉で整理する。

カバレッジ分析は「テストしてないコードを見つける」のが仕事。それ以上でも以下でもない。

「カバレッジが何%である」という事実に意味なんてない。

そこに意味を見出すのは、開発者自身である。

たとえば、ある関数のカバレッジが「85%」であり、カバーされてないコード部分が見つかったとする。

この事実を開発者であるあなた自身が把握し、テストケースを追加すべきか、変更すべきか、放置でいいのかを判断すべき

「85%だから100%になるように機械的にテストケースを作ろう」という思考ではダメ。

それでは全く意味がない。無駄な、むしろ悪影響のあるテストケースを作る恐れすらある。

「このコードがテストにカバーされてないとしても、〜という理由で無視して良い」といった言語化ができないなら危ない。

その関数の仕様がどういうものであり、どういう検証が必要なのかを理解し切っていない。

逆に、カバレッジが「100%」だから安心というのも危険。

カバレッジ中心にしてテストケースを作ってしまうと、必要なテストケースが不足する。

カバレッジ分析なんてのは、テストの中心にいるものではなく、ただの補助ツールでしかないと心得ておく。

そんな大したものではないし、まして、崇拝するものでもない。

ラフに「この関数、テストしてない箇所とかあるかなぁ？」程度に使うもの。

重要なのはカバレッジではなく...

「その関数が仕様通りに動くことを質高く検証できているか、リスクとのバランスも鑑みて十分か」を考えること

よくある誤解

table:

誤解 現実

カバレッジ85%達成! = 品質が高い ただの数字、品質とは無関係

100%を目指すべき 思考停止したテストの山

カバレッジが低い = 問題 シンプルなコードなら問題なし

シンプルな考え

code: txt

1. カバレッジツールを実行

2. 「テストされていない部分」を発見

3. その部分を見て自問:

「これ、テストしないとヤバい?」

- 複雑? → テストすべき

- シンプル? → 無視してOK

- クリティカル? → テストすべき

4. 終わり