Happy Testing Perl

第4回 Test::Perl::Critic, Test::Pod, Test::Pod::Coverage, Test::Exception, Test::Warn, Devel::Coverの紹介

この記事を読むのに必要な時間:およそ 3 分

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

Test::Perl::Critic

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

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/ ;

著者プロフィール

小林篤(こばやしあつし)

株式会社モバイルファクトリー システム開発部所属。

携帯公式サイト構築をはじめ,公式サイトで利用する楽曲を管理するプロジェクト開発を担当。インフラ関係ではメールサーバを構築運用したりもしている。

ネコが大好きだが,ネコアレルギーなこまったぷろぐらま。

ブログはhttp://d.hatena.ne.jp/nekokak/など。

バックナンバー

Happy Testing Perl

コメント

コメントの記入