どうもSuです。
「Googleソフトウェアエンジニアリング」という知識の宝庫をちょくちょく読んで、知見や感想をまとめています。今日はコードカバレッジ編です。
コードカバレッジって何？
テストコードが、どれくらいプロダクションコードをを網羅したか（通過したか）を計る指標です。C0（命令網羅）、C1（判定条件網羅）、C2（条件網羅）といった異なる指標があります。
Googleさんとしての見解は？
「カバレッジがゴールになっているのがしばしばみられるのは残念」、「カバレッジの計測は、小テストレベルにとどめている」といった感じのようです。
コードカバレッジって計測した方がいいの？
個人的な意見としては「単体テストレベルであれば、Yes」です。
もちろん、Googleさんが言うように、「コードカバレッジ100％が目標だ！」と意気込んでやる必要はありません。
自分が感じていることは、コードカバレッジを高める過程で
「あまり意識していなかったコードの存在に気づく」
ということです。
コードカバレッジで気づくこと
今の現場では、実装＋単体テストコードを書くのが通常なのですが、コードカバレッジを見ると、どのコードがテストを通過していないかが分かります。
その中には、「try-catchでエラーハンドリングしたコード」も含まれます。ここが意外と盲点なのです。
異常系のコードはしっかり書かない？
自分の経験上、普段の開発で、正常系のコードは良く吟味して書くのですが、「異常系のコードはおざなりになりがちです」（怒られそうですが）
そんな時、テストコードを書いて、異常系のコードを動かしてみると、「あれ？エラーで落ちる」と言ったケースがあります。
普段から気を付けていれば良いのですが、機能としては正常系が動かないとどうしようもないので、どうしても異常系は優先度が下がりがちです。
異常系のコードをしっかり見ると何が良い？
異常系というのは、リリース後に役に立つことが多いです。
「リリース後からエラーが発生しているのだけど、原因は何だろう？」と考えたときに、「異常系のログをしっかし出していたから、原因が判断しやすかった」というのは異常系がちゃんと設計できてた良い例でしょう。
カバレッジを見ることで全体コードを見直せる
カバレッジ計測をしていると、一通りのコードをテストコードで通すように作業を進めていくと思います。
その時、関数の書き方が複雑になっていたりすると、「テストコードが書きづらい」という事実に気づきます。
そうなってくるとリファクタリングのチャンスです。コードを改善し、より保守性の高いテストを書くことができますね。もし、カバレッジを取っていなかったら、気づけなかったかもしれません。
最後に
コードカバレッジは、役に立つ指標の1つではあります。
しかし、最初は目指していなかったとしても、「カバレッジを100%にする！」に目標が変わりがちです。
本来の目的やカバレッジを目指したことによるトレードオフを考慮することが大事な事ですね。
この記事が役に立ったと思って頂けた方は、「Amazonリンククリックのみ（購入不要）」で構いませんので、ポチっと応援していただけるとうれしいです。