Hatena::Groupdann

dann's blog このページをアンテナに追加 RSSフィード

Fork me on GitHub

2008-07-21

Devel::Coverでカバレッジテスト

| Devel::Coverでカバレッジテスト - dann's blog を含むブックマーク はてなブックマーク - Devel::Coverでカバレッジテスト - dann's blog Devel::Coverでカバレッジテスト - dann's blog のブックマークコメント

機能テストで機能仕様を満たしているかを確認するのにテストケースを書く場合、それらのテストをしていてもカバレッジが100%になっていなければ、何らかの漏れがあるか、使われていない古いコードが残っているかの可能性が高くなります。どちらのケースも後々になって問題が大きくなってきます。

特に製品規模が大きくなればなるほど、使われないコードが残存するというのは、割とよくあるケースで、使われないコードが増えだすと、どこに手をいれてよいのかがわかりにくくなってきます。こうなってくると、段々とコードを変更する事が大変になってきます。

テストケースがあったとしても、カバレッジが低ければ、どこを触ってもデグレードしてしまう危険があるからです。

特に企業で開発する場合、ずっと一人でメンテをするということはなく、開発メンバは変わっていきます。このような場合に、テストカバレッジが低いと大変です。

2-3人で開発をしていて、全体を全ての人が把握しきれているという状態が未来永劫続く環境があれば、カバレッジが低くても何とかなりますが、現実的にはそのような状況は存在しえません。長い目でみると、カバレッジを高く保つ事は、保守性を高め、結果プロダクト開発の生産性を高めることになります。

Perlでは、このカバレッジテストをするためのモジュールとして、Devel::Coverというモジュールが存在します。http-engineの例を見ると、以下のようなスクリプトでcoverageを、Devel::Coverを使って測定しています。

#!/bin/zsh
rm -rf cover_db
make realclean
perl Makefile.PL
HARNESS_PERL_SWITCHES=-MDevel::Cover=+ignore,inc,-coverage,statement,branch,condition,path,subroutine make test
cover
open cover_db/coverage.html

上記のスクリプトに少し手を加えて、cronで日付単位で結果を生成するようにして、indexを生成するスクリプトを作っておけば、日常的にカバレッジを確認できるようになりますね。

特に、開発の中盤から後半、またサービスのリリース後においては、テストカバレッジが高い状況を作り出しておくと、いざ開発メンバが変わったときでも安心して開発ができるのではないかと思います。