nDiki : リグレッションテスト

リグレッションテスト (回帰テスト) - regression test

プログラムを修正した際に、新しい問題(バグ、仕様違反)が生じていないかをチェックするソフトウェアテストの事。

web

http://www.atmarkit.co.jp/...

2004年12月7日 (火)

■ Test::Harness を Perl モジュール開発以外で使う

スポンサードリンク

Test::Harness モジュールに、単独で Test::Harness 用のテストファイル(群)を実行できる prove というツールがついているのを発見。

スクリプトのちょっとしたリグレッションテストを書いたりするのにこれはいい。ダミーのパッケージを作る(autoconfiscate するとか Makefile.PL 作る)とか、自前でスクリプトを書くとかしないで済む。書きなれたスタイルでテストコードが書けるし。

tpage (Template Toolkit) 用テンプレートをいじる時にリグレッションテストをかけられるようにしたかったで、使ってみることにする。

◇ Twitter やってます。この記事が気にいったらぜひ twitter.com/Naney の follower になってください。

[ permalink ]

Module::Build でソースパッケージング (2005-08-24)
WiKicker の Makefile.PL を Module::Inst... (2006-02-10)
ExtUtils::ModuleMaker::TT (2004-10-17)
Ming 0.3 beta 1 を Debian に (2005-02-18)
Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)

[ 12月7日全て ]

2005年8月24日 (水)

■ Module::Build でソースパッケージング

@ ExtUtils::MakeMaker

私が Perl が好きな理由の一つに、標準でExtUtils::MakeMakerという Makefile ジェネレータがついているところである。これを使って Makefile.PL を書くと

 perl Makefile.PL
 make manifest
 make
 make test
 make dist

で <pacakge>-<versionno>.tar.gz というソースパッケージを作ることができ、

 tar zxvf <pacakge>-<versionno>.tar.gz
 cd <pacakge>-<versionno>
 perl Makefile.PL
 make
 make test
 make install

という手順でインストールする事ができるようになる。パッケージの作り方が確立されているので、容易に新しいパッケージを開発しはじめられる。

逆に Java でプログラムを書くのが億劫なのは、このあたりの準備が面倒だからである。 Ant を使っても結局ここら辺自分でやらなければならないし。

@ ちょっとしたアーカイブの作成

ちょっとしたパッケージを作りたいと思うことは良くある。例えばいくつかのデータファイルと、READMEファイルなんかをひとまとめにしてアーカイブにするとか。

本当にちょっとしたであれば、手動でアーカイブすれば良いのだが、

アーカイブしたいファイル群がバージョン管理下にあって、CVS ディレクトリや .svn ディレクトリがある (除外してアーカイブする必要がある)
同じディレクトリにある、作業用のファイルはアーカイブしたくない (除外してアーカイブする必要がある)
アーカイブする前に、チェック用のリグレッションテスト一式を走らせたい (リグレッションテストをかけられるようにする)
UNIX でも Windows でもアーカイブ化できるようにしたい。

あたりを考慮しなければならない時は面倒くさくなってくる。

自動化としては

シェルスクリプト/バッチファイルを書く
Makefile を書く
GNU Autotools を使う

あたりがぱっと思い浮かぶ。しかし、最初の2つは毎回同じようなものを書くのが面倒だし保守もしにくい。 GNU Autotools はちょっとごっつすぎだし、Windows での環境構築も面倒。

@ ExtUtils::MakeMaker の欠点

ということで最初は ExtUtils::MakeMaker を使うという線で考えてみた。もともと Perl モジュール用で汎用用途にはちょっと邪魔な振舞いもあるが、使えないことはないと思う。しかし make (GNU Make あるいは nmake など) に依存しているという欠点がある。

@ Module::Build で

ということで ExtUtils::MakeMaker の代替である Module::Build ベースで汎用用途に使えないか検討してみた。こちらは pure Perl で make を必要としない。

Module::Build も Perl モジュールビルドにあわせた振舞いがあるものの、ちょっとカスタマイズすれば使えそうだ。で、いろいろいじった結果、次のような感じにすると使いやすそうだ。

 use Module::Build;
 my $class = Module::Build
   ->subclass(class => 'NonmoduleBuilder',
              code => q{
                        # Don't make blib
                        sub ACTION_code {};
                        # Don't make blib
                        sub ACTION_docs {};
                        # Don't make META.yml
                        sub ACTION_distmeta {
                          # no warning on ACTION_distdir
                          $_[0]->{metafile} = 'MANIFEST';
                        };
                        # Don't add MEATA.yml to MANIFEST
                        sub ACTION_manifest {
                          $_[0]->{metafile} = 'MANIFEST',
                          $_[0]->SUPER::ACTION_manifest(@_);
                        };
                       });

 # Set your archive name and version.
 $class->new(dist_name => 'mypackage',
             dist_version => '1.0.2',
             )->create_build_script;

カスタマイズした部分は以下(Module::Build 0.26 で動作確認)。

Perl モジュールビルドに特有の blib ディレクトリを作らないようにする。
META.yml を生成しないようにし、アーカイブに含まれないようにする。

上記のようなファイルを Build.PL という名前で作っておけば

 perl Build.PL
 ./Build manifest
 ./Build
 ./Build test
 ./Build dist

等として、アーカイブ作成が容易にできるようになる。

しばらくこの方法でいろいろ試してみることにしてみよう。

[ permalink ]

SCons は GNU Autotools のかわりになるか (2005-04-20)
ActivePerl で Ming (2005-02-23)
nmake で毎回 pl2bat されるのを何とかしたい (2004-11-25)
私的10大ニュース2004 [ comp ] (2004-12-31)
WiKicker の Makefile.PL を Module::Inst... (2006-02-10)

[ 8月24日全て ]

2006年2月18日 (土)

■ Perl CGI プログラムのテストには WWW::Mechanize::CGI を

CGI プログラムを書いていて、いつも困るのがリグレッションテスト。

パッケージのビルド時に実行するテストスーツ (make check / make test 用テストプログラム群) に含めておきたいが、さすがにその場で Web サーバの下へセットアップするわけにもいかない。ミニ Web サーバを同梱してテストスーツ内で起動する方法はちょっとおおがかかりだし、ポート番号の選択やらサーバの停止の問題もあって、かなり面倒。

結局、テストスーツの中で環境変数や標準入力など CGI リクエスト環境をセットアップして、CGI プログラムを実行するという王道(?)かつ泥臭いテストを書くことになったりする。

何かいいものはないかと探していたところ、WWW::Mechanize::CGI というものをみつけた。

LWP::UserAgent を継承した WWW::Mechanize モジュールは Web ブラウジングを容易にする有名どころのモジュールである。

WWW::Mechanize::CGI モジュールはさらにこれを拡張したモジュールで、HTTP リクエストを、仮想的に CGI プログラムやサブルーチンへの呼出しにしてくれる。これを用いるとあたかも Web サーバ上の CGI プログラムにリクエストしレスポンスを受けとっているかのように、テストプログラムを書くことができる。

素晴しい。

さっそく WiKicker のテストを書き換えてみた:

 use Test::More tests => 2;
 use WiKicker::WikICGI::Controller;
 use WWW::Mechanize::CGI;
 use File::Temp qw(tempdir);
 use File::Spec;
 my $www_dir = tempdir(CLEANUP => 1);
 my $mech = WWW::Mechanize::CGI->new;
 $mech->cgi(sub {
              $ENV{PATH_INFO} = '' if $ENV{PATH_INFO} eq '/';
              WiKicker::WikiCGI::Controller->new->run});
 $mech->env($mech->env,
            SCRIPT_FILENAME => File::Spec
                                 ->catfile($www_dir . '/wiki'),
            SCRIPT_NAME => '/wiki');
 my $response = $mech->get('http://localhost/wiki');
 ok($response->is_success);
 like($response->content,
      qr|<title>WikiForum\[WiKicker\]: FrontPage</title>|);

WWW::Mechanize::CGI オブジェクトを new した後、cgi メソッドで CGI サブルーチンを指定するか、cgi_application メソッドで外部 CGI プログラムを指定する。ここでは直接、CGI サブルーチン (WiKicker::WikiCGI::Controller->new->run を実行)を指定した。

なおここで WWW::Mechanize::CGI が使っている HTTP::Request::AsCGI 0.5 における PATH_INFO の扱いが Apache などとは違って、空でも必ず '/' が入るようになっている。これだと WiKicker では困るので、サブルーチンのところで修正している。

後は必要ならば WWW::Mechanize::CGI::env で、追加の環境変数設定を行っておく。

セットアップが済めば通常の WWW::Mechanize と同様に get 等でリクエストを行いレスポンスを受けとることができるようになる。

いい。しばらく試してみて不具合がなさそうなら、定番のテストスタイルにしたい。

ちなみに Test::Harness 用の Test::WWW::Mechanize にあわせて、Test::WWW::Mechanize::CGI というものもある。これらを用いるとさらにテストを書くのが楽になるが、依存するモジュールも多いので無理に使わないほうがいいかもしれない。

[ permalink ]

一般ユーザで Apache 2.0 を起動する最小限の httpd.conf (2006-07-15)
Test::WWW::Mechanize で Web アプリケーションをテ... (2006-09-13)
[ WiKicker ] SpeedyCGI (2003-10-17)
XAMPP で WiKicker を動かしてみた。PPM インストール OK。 (2007-02-09)
他の Web サイトの情報を URI::Fetch でキャッシュ付き取得 (2005-10-29)

[ 2月18日全て ]

2006年9月13日 (水)

■ Test::WWW::Mechanize で Web アプリケーションをテストファースト開発

テストファースト開発に慣れてしまうと、テストコード無しにプログラムを書くというのは不安でたまらなく感じてくる。

テストが欲しい。安らぎが欲しい。

今開発している WiKicker ベースの Web アプリケーションもだんだん機能が増えてきて、コードを触るのがコワくなってきた。

今回は Basic 認証等もあるので、WWW::Mechanize::CGI ではなくてきちんと deploy してから Test::WWW::Mechanize でテストすることにした。

Test::WWW::Mechanize、使ってみると WWW::Mechanize + Test::More よりテストを書くのも読むのも楽になった。

deploy が必要なリグレッションテストはさすがに t/ の下に入れておくのはどうかと思う。プロジェクト的にはビルドサーバを用意して、そこで自動的にテストできるような環境を用意するのが良さそうだ。

[ permalink ]

Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)
一般ユーザで Apache 2.0 を起動する最小限の httpd.conf (2006-07-15)
「依存関係検査のしにくいモジュール」に依存するスクリプトをPARで実行形式化する (2005-03-08)
[ WiKicker ] SpeedyCGI (2003-10-17)
今日のさえずり - 京都の小学校のコンピュータ室にいったら、Squeak が (2008-03-06)

[ 9月13日全て ]

2008年6月14日 (土)

■ スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。

自分がプログラムをスクラッチから書き直したいと思った時、またスクラッチから書き直したいと言われた時のためにまとめておこう。

@ スクラッチから書き直したい理由

スクラッチから書き直したいと思う理由はだいたいこうだ。

もっと良くできると思うから
- 「もっと良いやり方がある」「自分ならもっとうまく書ける」
- 「統一されていない」「もっと汎用的にできる」
- 「今なら新しい開発環境(・新しい実行環境・新しいライブラリ・新しい言語)を使って簡単によりいいものが素早く作れる」
よくわからないいから
- 「何をやっているかわからない」「どう直していいかわからない」
- 「もう直しようがない」
- 「作り直した方がはやい」
あいつのだから
- 「あいつが書いたコードだから」

どんなプログラムでも開発が進み詳細がわかってくると、こうしておけば良かったと思う点がでてくるものだ。

さらに、他人が書いたプログラムだとよく分からない。

It's harder to read code than to write it. (プログラムというのは書くより読むほうが難しい。) -- Things You Should Never Do, Part I - Joel on Software

いっそ作り直してしまいたいと思うのはどの開発者でもあることだ。

@ スクラッチから書き直してはいけない理由

しかし多くの場合スクラッチから書き直すことはリスクとデメリットだらけだ。

今までの投資を失うから
- 「そのプログラムには検討・不具合修正に膨大なエネルギーが投入されている」
- 「ユーザは今のプログラムのために学習コストをかけている」
時間がかかるから
- 「その新しいプログラムが今と同じレベルの価値を実現するまでは時間がかかりすぎる」
- 「スクラッチし直してから投入したのでは、もはや価値を失っている可能性が高い」
前轍を踏むから
- 「どう直していいかわからないと思う時は往々にして目標がわかっていない。目標がわからずに作ったものは結局またスクラッチから書き直したくなる」
- 「あなたが連続的にプログラムを修正できないというのなら、どちらにせよ新しく作り直したプログラムもあなたは連続的にプログラムを修正できない」(リグレッションテストの習慣はあるの? リファクタリングスキルはあるの?)