nDiki : HTTP::Request

スポンサードリンク

2004年6月7日 (月)

■ ハイパー日記システムと Log::Log4perl

朝、Naney's Diary をチェックしたらエラーが出てしまっている。昨日 WiKicker をアップデートした事による影響か。

チェックしたところ、hns ではライブラリに HTTP というパッケージがありその中で Request サブルーチンが定義されていた。これが HTTP::Request モジュールと被っており、今回 WiKicker の更新で間接的に使用されることになった Log::Log4perl の中での new HTTP::Request と衝突する事に。

名前空間大事。

hns の方の HTTP::Request サブルーチンはそのパッケージ内でしか呼ばれていないようなので、HTTP::RequestSub と名前を変更して対処。

スポンサードリンク

[ permalink ]

WiKicker 0.30 リリース - トップページのページ名を変更でき... (2006-05-22)
Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)
Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
[ Perl ] Log::Log4perlのはまりどころ (2004-03-02)
WiKicker における PageName 最長文字数 (2006-06-10)

[ 6月7日全て ]

既に HTTP::Daemon で作成されているHTTPサーバで、XML-RPC インタフェースを提供したい。前回のチェックで XMLRPC::Lite を使う事にした(RPC::XML は ActivePerl 5.6.1 build638 でテストが通らない)。このパッケージで用意されているサーバ向けモジュールは、主に単独CGI プログラムで使うモジュールと、自前で HTTP::Daemon をまわすサーバタイプ。

そのままでは使えないので、以下のように。

XMLRPC::Transport::HTTP::CGI のサブクラスを作成し、handle をオーバライドする。中身は SOAP::Transport::HTTP::Server::handle を呼ぶだけ (SUPER::handle では駄目)。
XML-RPC リクエストがきたら、上記インスタンスの request メソッドで HTTP::Request オブジェクトを渡す。
handle を実行。
response メソッドで HTTP::Response を受け取り、クライアントに送信。

handle メソッドで入出力をさせないようにするのがポイント。

[ permalink ]

Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)
HTTP::Daemonベースのプログラムのテスト (2004-11-26)
RPC::XML のかわりに XMLRPC::Lite (2004-08-31)
www.naney.org に「友人・知人に紹介メール」ページを新設 (2000-12-27)
HTTP::Daemon - パイプが切断されました (2004-06-29)

[ 9月14日全て ]

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 ]