モバイルファクトリーの小林です。今回は今までに紹介しきれなかったPerlのTestingモジュールで良く利用されるものをいくつか紹介したいと思います。

Test::Perl::Critic

このモジュールはテスト対象のコードがPBPに準拠しているかどうかをテストしてくれるモジュールです。 PBPとはDamian Conway氏の提唱するPerl Best PracticesというPerlのコードを書く際のスタイルです。

• http://www.oreilly.co.jp/books/4873113008/

Perl Best Practicesについての詳細はこちらをご覧ください。

Test::Perl::Criticを使うには、t/99-perlcritic.t というようなファイルを作って、

use strict;
use Test::More;

eval { require Test::Perl::Critic; Test::Perl::Critic->import(-profile => "t/perlcriticrc") };
plan skip_all => "Test::Perl::Critic is not installed." if $@;

all_critic_ok("lib");

このように書くだけです。 Test::Perl::Criticは内部で、Perl::Criticを使っています。Perl::CriticはPerl Best Praciticeに書かれているスタンダードなPerlのコーディングスタイルをチェックし、2引数のopenなど危険なcodeがないかチェックしてくれますので、ぜひ使ってください。

GLOB操作をする場合、“⁠no strict 'refs'⁠”と書くことがあります。

no strict 'refs';
*{"$package\::$method"} = sub { }

しかし、Perl::Critic的には“⁠no strict⁠”なコードは許可しておらず、エラーとなります。 そこで、開発者が“⁠no strict⁠”は意図しており、PBP準拠から外れるかもしれませんが、どうしても必要という場合は

no strict 'refs'; ## no critic

のように記述することで、Perl::Criticがそのコードを無視してくれるようになります。

デフォルトのPBPのルールだと厳格すぎる部分があるので、必要に応じて、t/perlcriticrcというファイルに以下のようなPBP回避ルールを書くことでPBPのルールに幅を持たせることも可能です。

# no strict 'refs'
[TestingAndDebugging::ProhibitNoStrict]
allow = refs

Test::Pod

このモジュールはPOD（Plane Old Document）として正しいかをテストしてくれます。使い方は簡単で以下のようなコードを t/96_pod.tのように用意するだけです。

use Test::More;
eval "use Test::Pod 1.00";
plan skip_all => "Test::Pod 1.00 required for testing POD" if $@;
all_pod_files_ok();

これにより、モジュール内に書かれたPODに誤りがあるとテスト実行時に通知してくれます。

Test::Pod::Coverage

このモジュールはテスト対象となっているプログラムに存在するMethodなどが、もれなくPODが書かれているかをテストしてくれるモジュールです。 こちらも使い方は簡単で以下のようなコードを t/97_pod_coverage.tの用に用意するだけです。

use Test::More;
eval "use Test::Pod::Coverage 1.04";
plan skip_all => "Test::Pod::Coverage 1.04 required for testing POD coverage"
   if $@;
all_pod_coverage_ok();

Test::Exception

第3回で紹介したTest::Declareでも利用しているモジュールです。このモジュールでは各種例外についてテストする事が可能です。 たとえば、以下のようなモジュールがあるとします。

package SomeModule;
use strict;
use warnings;

sub foo {
   my ($class, $args) = @_;
   unless ($args) {
       die 'args error!';
   }
   return $args;
}

1;

このモジュールをテストする際、わざわざメソッド呼び出しの部分をevalブロックで囲んで$@をチェックするのは面倒、かつ一体何をテストしているのかが不明瞭となります。

use SomeModule;
use Test::More;
plan tests => 1;

eval { SomeModule->foo };
ok $@,

しかし、Test::Exceptionを利用すれば、このように書くことができます。

use SomeModule;
use Test::More;
use Test::Exception;
plan tests => 1;

dies_ok {SomeModule->foo};

evalを使ったテストよりも例外が発生することを明瞭にテストすることが可能です。 Test::Exceptionではthrows_okなどのメソッドも用意されており、throws_okを利用すれば例外発生時の$@の内容をテストすることも可能です。

use SomeModule;
use Test::More;
use Test::Exception;
plan tests => 1;

throws_ok { SomeModule->foo } qr/args error/ ;

Test::Warn

このモジュールもTest::Declareで利用しているモジュールで、Text::Exceptionと異なり、warningsが発生したことをテストするモジュールです。

たとえば、先ほどのSomeModuleのfooメソッド呼び出しの際、dieするのではなく、以下のようにwarnを出すとします。

package SomeModule;
use strict;
use warnings;

sub foo {
   my ($class, $args) = @_;
   unless ($args) {
       warn 'no args!';
   }
   return $args;
}

1;

この場合ではTest::ExceptionではなくTest::Warnを利用します。利用方法は以下のようになります。

use SomeModule;
use Test::More;
use Test::Warn;
plan tests => 1;

warning_like { SomeModule->foo } qr/no args!/ ;

このモジュールを利用しなくてもテストする方法はもちろんあります。一例としては以下のようなテストです。

use SomeModule;
use Test::More;
plan tests => 1;

my $warnings;
local $SIG{__WARN__} = sub {
   $warnings = shift;
};

SomeModule->foo;

like $warnings, qr/no args/ ;

Test::Warnを利用したテストコードのほうが、何をテストしたいのかがはっきりしています。テストコードを書く際にはこのコードでどのようなテストをしたいのかがわかるように書くと、全体として見通しの良いテストコードとなりメンテナンスしやすくなることでしょう。

Devel::Cover

このモジュール自体が何かをテストしてくれるわけではありませんが、テストコードのカバレッジ率を調べるのに役立つモジュールです。

使い方は簡単で、Devel::Coverモジュールをインストールしたら以下のように実行するだけです。

$ perl Makefile.PL
$ cover -test -ignore_re "^inc/"

実行後に結果のHTMLが生成されるので、それを見れば、どのメソッドのテストケースが不足しているのかが一目瞭然となります。

Devel::Coverでは以下の網羅率を調べることができます。

テストコードはただ量を増やせばいいのではなく、さまざまな条件をカバーするテストを書く必要があります。このモジュールを利用することによって、どれだけのコードがテストによってカバーされているかを視覚的に判断することができるのが魅力です。

ただ、このモジュールを利用してテストを実行すると、テスト全体の実行時間が通常よりもかかってしまうので、通常の開発時にはチェックせず、一通りのテストが用意できた段階で、カバレッジ率を見るように実行したほうが良いでしょう。

まとめ

Perlには本当にたくさんのテスト用モジュールが存在します。これらのモジュールを利用して、快適なテスト生活を送れるよう頑張ってください。

Happy testing!