品質の高いソフトウェアを作るのが目的なのだから、カバレッジ100％が目標なのではなく、バグの発生率0％が目標のはずだ。ツールに頼ってベンチマークにする数値を間違えてはいけないよね。ま、そういうお話。
Martin Fowler’s Bliki in Japanese – TestCoverage.
カバレッジの数値がほしい理由はわかる。テストが十分かを知りたいのだ。カバレッジの数値が低い場合、たとえば50%以下の場合は、おそらく問題があるだろう。けれど高いカバレッジの数値にはあまり意味はない。ダッシュボードの数字に意味がなくなる助けをするだけだ。以下の質問に「はい」と答えられるならば、おそらくテストは十分だろう:
- 本番環境で発見されるバグはほとんどない。そして、
- 本番環境でバグを出すことを恐れてコードの変更をためらうことがない。
テストしすぎることは可能だろうか？もちろん。テストをいくつか削除しても、テストが十分なら、テストしすぎである。ただ、それを見分けるのは難しい。テストによって開発速度が落ちているなら、テストしすぎの兆候である。コードの単純な変更の結果、テストを延々と修正する必要があるなら、これはテストに問題がある兆候だ。テストをしすぎているのではなく、おそらくテストが重複しているのだろう。
テストに時間がかかりすぎるから、テストしすぎだと考える人もいる。この考えにはあまり説得力はない。遅いテストは、デプロイメントパイプラインの後のステージにいつでも移せる。もしかすると、パイプラインから外して定期的に実行でもよいかもしれない。テストからのフィードバックは遅くなるが、それはビルド時間とテストに対する信頼度とのトレードオフだ。
で、カバレッジ解析の価値は何なんだろう？まずは、テストが不十分なコードを見つけるのに役立つ。カバレッジツールをしょっちゅう実行して、テストのないコードを見つけておくのは価値のあることだ。それらのコードがテストされていないことで不安になるだろうか？
テストスイートにカバレッジによって見つかる問題点があるなら、おそらくカバレッジによって見つけられない問題点も抱えている可能性が高い。 — Brian Marick
コメント