コードカバレッジで見落とされがちだと思う事

はじめに

みなさんがいろいろ言いたい事はあるだろうから、むしろみなさんの意見を聞きたい。はてなブックマークのコメントとかではなく、直接このブログのコメントか引用した自身のブログで書いてくれれば幸いだ。

コードカバレッジ

日本語で20冊くらい書籍がでているようなプログラミング言語で、しかもテスティングフレームワークについても紹介されているような言語であれば、最近ではだいたいは「テストコードの実行によって実行されたプロダクトコードのパスカバレッジを計測するツール」であるところのコードカバレッジツールはあるでしょう。 JavaであればJaCoCoというツールがありますし、最近だとCoverallsというサービスもありますね。

どれくらいだといいのか？

コードカバレッジがバグ検出と強い因果関係にはなさそうであるというのが、自分の周りで聞く事が多くなりました。また、先日そういった論文も発表されたようです。（Twitterで見かけたのですが、どの学会だったかいま調べ中です。あとで追記します。）

ですが、まぁある程度は相関関係がありそうですし、保守性向上には寄与しているとよく感じるので、出来るだけそれなりのカバレッジを保つように書いている事がほとんどではないでしょうか。そして僕は現状はそれで正しいと思います。

ですが、実際にどういった方法でどれくらいの数値がいいのだろうか？というのはまま気になる部分ですし、目標があったほうが人間はやりやすいし、ダメかもーって警告があるほうがやりやすいというのもあります。

で、よく勉強会で聞く話だと80%前後ではないだろうか？みたいなことは聞きますね。（たぶんその場で限定出来るコンテキストがどの勉強会でも似ているから、同じくらいの数値に落ち着くのではないだろうかと思っている。）

実際に自分がやってみてよかったこと

少し前までこういったことをさぼっていまして、最近自分の中で何かうまくいかないなぁと感じ始めて計測してみました。 それでわかったことは、全てのテストレベルで同程度以上のコードカバレッジを達成していると品質に寄与するということでした。つまり、UnitTestで80%超えているんだけど、IntegrationTestで30%くらい。という状況だとちょっとバグが出やすくて、両方で80%超えているとバグが出にくいということでした。

まぁ当然と言えば当然なのかもしれませんけど、逆にIntegrationTestで80%でも、UnitTestが30%とかだとバグが出やすいという傾向がありました。 単純にどんなテストでもいいからとか簡単には言えないとは思うのですが、今のメンバーでやっている限りは社内で可能な自動テストであればどれであっても80%くらいを保っているのがよさそうです。

よかった理由の憶測

なぜそうなのか。という憶測は次の通りです。

• テストケースの重複を減らす事よりも、対象が何であるかをより多角的に捉えていることが品質をあげている
• どちらでもある程度のコードカバレッジがあると、リストラクチャリングを行いやすくなる
• 保守性やリリースしやすさに自信を持ちやすくなってポジティブに開発をしやすくなる

継続的デリバリーにも書いてあった

と、思えば、継続的デリバリーにもしっかり書かれている事を思い出しました。実際の経験と合致したのは面白いですね。

ここでいう自動テストのカバレッジには、ユニットテストやコンポーネントテスト、受け入れテストが含まれている。そして、それぞれがアプリケーションの 80%をカバーし ていなければならないのだ(ユニットテストのカバレッジが 60%で、受け入れテストのカバレッジが 20%であれば合わせて 80%であるという素朴な考え方には与しない)。

継続的デリバリー 第４章 テスト戦略を実装する p.131

まとめ

ということで、コードカバレッジがあるテストレベル単体でいくつって見るだけじゃなくって、複数のテストレベルのテストコードでそれらを満たしましょうっていうのが、あくまで自分の周りだと見落とされがちか話されていないか気にされていないかなぁと思いました。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化