ソフトウェア開発組織が持つべきカルチャー(17) [ソフトウェア開発組織が持つべきカルチャー]
コードカバレッジを品質基準としない
「API設計の基礎」の3.8節「コードカバレッジと防御的プログラミング」では、次のように述べています。テストコードによるコードカバレッジは、そのソフトウェアの品質を担保しません。コードカバレッジが100%だから、品質が高いとは限りません。バグがあるコードでも、テストでコードカバレッジを100%にすることはできます。ある機能を持つモジュールを開発する場合、そのモジュールのAPI設計が重要になります。APIの仕様には機能や使い方はもちろんのこと、不正なパラメータの場合の振る舞いが記述されていなければなりません(参考:「API設計の基礎」)。
そして、テストコードとしては、その仕様を検査するテストを書くことになります。①適切なAPI仕様、②それに基づく適切なテスト、そして実装です。実装がテストに合格したら、コードカバレッジを計測するわけです。コードカバレッジでは、コードの実行割合ではなく、実際に実行されたコードがどの行で、どの行が実行されていないかを見る必要があります。もし、実行されていないコードがあれば、その理由を考えます。テストが不足しているのであればテストを追加しますし、不必要なコードを書いていればコードを削除するかもしれません。あるいは、防御的プログラミングのために実行されないコードなら、そのままにしておくかもしれません。
このような開発では、①の「適切なAPI仕様」が記述されているかが、まずは重要です。私自身は、多くのAPIのレビューをしてきましたが、適切にAPIを定義できないエンジニアが多いです。ソフトウェアの経験年数が浅いためにできない人もいれば、ソフトウェアの経験年数が長くてもできない人もいます。この①ができていなければ、コードカバレッジは無意味です。残念ながら①の品質を静的に解析できるツールはありません。経験を積んだスキルの高いエンジニアにレビューしてもらうしかないのです。
②の「適切なテスト」では、仕様通りであるかに加えて、入力パラメータの組み合わせが網羅されているかも重要です。不正なパラメータの検査、境界値分析、同値分割などを適切に取り入れる必要があります。①がきちんとされてない場合、②のテストは正常なケースだけだったり、テスト範囲が狭かったりします。不適切なテストを実行した結果のコードカバレッジも、再び無意味です。したがって、ソフトウェアエンジニアは、テスト設計に関する技法もきちんと学ぶ必要があります。
コードカバレッジの数値が、ソフトウェアの品質を担保するわけではありません。しかし、①と②は静的に測定するのが困難なので、コードカバレッジの数値を単体テストの品質基準にしてしまっているソフトウェア開発組織が多くあるのではないでしょうか。たとえば、80パーセント以上のコードカバレッジをもって単体テストを完了とするとかです。そして、その数値だけが一人歩きを始めます。つまり、開発者や組織が、その数値をクリアするという視点だけで活動してしまうのです。極端な場合には、ソースコードを解析して、高いコードカバレッジとなるテストコードを生成する有償ツールを使って目標値を達成することまで行われたりします(もちろん、品質は向上しません)。結果として、①の「適切なAPI」を定義できなくて、②の「適切なテスト」を設計できないソフトウェアエンジニアを大量生産してしまいます。
残念ながら、コードカバレッジの数値目標を長年追っているようなソフトウェア開発組織では、①や②をきちんと行えるソフトウェアエンジニアが少なく、あるいはいなかったりして、①や②をきちんとレビューするという品質向上の活動ができなくなったりしています。
2017-05-06 05:28
コメント(0)
トラックバック(0)
コメント 0