カバレッジってどうなんだろうね？
Apache Hadoopの開発システムは、成功しているプロジェクトということもあって、かなりイケています。
パッチにテストコードが含まれているかどうかや、それが通るかどうか、スタイルが適切かどうか等を機械が自動的に判別してくれます。
そういう機械による開発効率化を是非普及させたいと思うわけです。ソフトウェア開発なんて工場製手工業だから、かけた手間賃しかもらえないわけで、それではよろしくない。もっとプラント化して、機械が製造してくれるようにしていってほしい。
テストを自動化する、これがユニットテストと呼ばれるものだ。それを評価するためにカバレッジなるものがある。要するにテストの網羅性の数値を機械が測ってくれますよというもの。
テストコードを書く人にはよい指標となると思う。しかし、コードを書かないし・読みもできない人にカバレッジで評価されたら困ると思う。
以下は、そういう事例は聞いたことがないが、恐れていることである。
まずカバレッジが100%であることを要求される。テストが書けるような設計を目指すべきだし、理想的には100%であったほうがよい。
しかし、現実にはテストが書けないようなところも出てくる。例えば、いちいちテストできない異常系とか。mallocで失敗した場合などだ。一応お作法として、コードとしては書く。
カバレッジを、コードを読みもできない人に数値として出したら、100%に満たないところは説明して、納得させなきゃならない。当然理解できないわけだが。その作業をしたところで、バグがなくなるわけでも機能が増えるわけでもない。無駄な作業だ。
３通りの選択肢しかない。
- 諦めて無駄な作業をする
- 数値を捏造する
- コードを悪い方向に直す
考えることすら面倒な人は１を選ぶ。要領のいい人は2を選ぶ。値を変えたことを説明できる材料は用意しておいて隠し持っておく。捏造に抵抗のある人は3を選ぶ。テストが書けないところを削るのだ。
おそらく、2がよく行われる選択肢なんだろうけど、それをするということは数値の意義を認めていないということだ。
だったら、最初からカバレッジなんて値で評価するのをやめるべきなんだろうと思う。(もちろんコードを読めない人がコードの評価しなければ一切の問題は生じない）
カバレッジが普及したらこういう問題がでるんじゃないかな？
