テストカバレッジ

テストカバレッジ（コードカバレッジとも呼ばれる）の目標値はどれくらいにすべきか、あるいはカバレッジレベルを誇らしげに語る人がいます。しかし、そのような発言は的を射ていません。テストカバレッジは、コードベースの中でテストされていない部分を見つけるための有用なツールです。テストカバレッジは、テストの質を数値的に示す指標としては、ほとんど役に立ちません。

まず、後者の発言を見てみましょう。「カバレッジが87%未満では本番環境に投入できない」と言う現場もあると聞いています。TDDを使って100%のカバレッジを達成しなければならないと言う人もいます。ある賢者はかつてこう言いました。

私は高いカバレッジレベルを期待します。マネージャーがそれを要求することもあります。そこには微妙な違いがあります。

-- Brian Marick（ブライアン・マリック）

一定のカバレッジレベルを目標に設定すると、人はそれを達成しようとします。問題は、質の低いテストでも高いカバレッジ数値を簡単に達成できてしまうことです。最も極端な例は、アサーションフリーテストです。しかし、そうでなくても、めったに発生しない問題を探すテストがたくさんあり、本当に重要なテストから注意をそらしてしまいます。

プログラミングのほとんどの側面と同様に、テストには思慮深さが必要です。TDDは非常に有用なツールですが、優れたテストを行うための十分な手段ではありません。思慮深く適切にテストを行っていれば、カバレッジは80%後半から90%台になるはずです。100%のような数値は疑わしいでしょう。カバレッジの数値を上げるためだけにテストを書いていて、自分が何をしているのか考えていないように思えます。

もちろん、人々がカバレッジの数値にこだわるのは、十分なテストを行っているかどうかを知りたいからです。確かに、半分以下の低いカバレッジ数値は問題の兆候です。しかし、高い数値は必ずしも多くを意味するわけではなく、無知を助長するダッシュボードにつながります。テストの十分性は、カバレッジで答えられるよりもはるかに複雑な属性です。次のことが当てはまる場合、十分なテストを行っていると言えるでしょう。

• 本番環境にエスケープするバグがほとんどない、かつ
• 本番環境のバグを引き起こすことを恐れて、コードの変更をためらうことがほとんどない。

テストをしすぎることはあるでしょうか？もちろんです。十分なテストを行いながら、テストを削除できる場合は、テストをしすぎていると言えるでしょう。しかし、これは感知するのが難しいことです。テストをしすぎている兆候の1つは、テストによって開発速度が低下している場合です。コードの単純な変更がテストに過度に長い変更を必要とする場合は、テストに問題があることを示しています。これは、テスト対象が多すぎるというよりも、テストに重複があることを意味しているのかもしれません。

テストの実行に時間がかかりすぎる場合、テストが多すぎると考える人もいます。私はこの議論にはあまり納得できません。実行時間の長いテストは、デプロイパイプラインの後半のステージに移動したり、パイプラインから外して定期的に実行したりすることができます。これらの対策は、テストからのフィードバックを遅くしますが、それはビルド時間とテストの信頼性のトレードオフの一部です。

では、カバレッジ分析の価値とは何でしょうか？それは、コードのどの部分がテストされていないかを見つけるのに役立ちます。[1] 定期的にカバレッジツールを実行し、テストされていないコードの部分を確認してみる価値はあります。それらの部分がテストされていないことに不安を感じますか？

テストスイートの一部がカバレッジで検出できるほど弱い場合、カバレッジでは検出できないほど弱い可能性もあります。

-- Brian Marick（ブライアン・マリック）

参考文献

Brian Marick（ブライアン・マリック）は、コードカバレッジの誤用に関する優れた記事を書いています。また、Testivus（テスティバス）の簡潔な解説を読む価値もあります。