Perl で狭義のモックを作る Test::Double 19:51

2010/07/27 19:51

Ruby の Mocha や Python の Mox は「特定の順序で特定のメソッドが特定の引数と呼ばれるか」というところにフォーカスしているように思う。

そもそも「モック」をそういう狭義の意味でつかう一派もいるらしい。Wikipedia の Mock object にはこうある。

Mock objects in this sense do a little more: their method implementations contain assertions of their own. This means that a true mock, in this sense, will examine the context of each call— perhaps checking the order in which its methods are called, perhaps performing tests on the data passed into the method calls as arguments.

その数個前の段落からリンクされている『レガシーコード改善ガイド』にはこうあった。

モックオブジェクトは、想定されるメソッド呼び出しを事前に設定し、メソッド呼び出し後に検証を指示することで、その呼び出しが実際に行われたかどうかを確認できる仕組みです。

さて、Perl の Test::MockObject にも next_call, call_pos といった「n 番目に呼ばれたメソッドはなにか、どうよばれたか」というのを検査する手段はある。でも、個人的には Mocha や Mox のようなインターフェースが好きなので Test::Double というのを書いてみた。

Test::Double

たとえば write_file メソッドが「引数に渡された $io に対して $io->print('hello') を呼び出す」みたいなことをテストしたいとすると

my $double = Test::Double->new;
$double->expects('print')->with('hello');
  
$double->verify_ok(
    sub { my $io = shift; write_file($io); }
);

こんな感じ。メソッド名は Mocha 風、verify を明示的に呼ぶのは Mox 風という感じで、ベタな移植ではない。

excepts は AUTOLOAD をハックしてメソッド呼び出し風に書けるほうが、と一瞬思ったけど、そうすると "excepts" というメソッドがあるクラスの振りをしづらいので、明示的にメソッドを呼ぶ形にした。あと Mox の Comparators をみて、メソッド風インターフェースの限界を感じたのもある。Perl でこういうの作るよりは Test::More::like とか使えるほうがうれしいと思う。

もうちょっと使ってみて、インターフェースとか固まったら CPAN にあげる予定。意見募集中です。

2Q をふりかえる 11:22

2010/07/04 11:22

2Q も終わり、ということは2010年も半分が終了してしまったわけです。はやい。

断線

2Q で一番おおきかったのは自宅のインターネット契約をきったことだ。OS のアップグレードが遅れがちになるとか、バザールモデルをとっているソフトウェアプロジェクトに参加しようという気がそがれるのとか、もちろん良くないところもあるんだけど、すごく困るかといえばそこまで困ってはいない。まあ、多少なりとも仕事に関係があるものは職場でみるし、家でも iPhone で Web をみることはアリにしてるしで、この2つも無くなってしまうと困るとは思う。

コンピュータとのつきあいかたの制限ないし制御は、なぜか The Economist でもみかけた。

読書

PragPub は新しいものがでるたびにダウンロードして読んでいるし "Framework Design Guidelines" も継続中。コンピュータがらみをふくむ翻訳もの (の原書) はできるだけ Kindle で読む気でいるので、本屋ではそうじゃないものを買うようにしている。ワーキングプアがどうこうというのはそれで読んだ。

そのほか

HTML5 は XML を捨てる理由がよくわからなかったんだけど、仕様書の一部を読んだらわかったので、そういうはなしを書いた。HTML5 をとりまくオフラインとかソケットとかはまだよくわからない。頭のいい人々ががんばれる余地が増えた、という印象が強いんだけど、いつか自分でも使うようになるのかなあ。

3Q にむけて

英語は Kindle でだらだら読んでるのと TOEIC 申し込んだのが 2Q で、試験日は 3Q です。なんかポップなものをつくりたいなー、というのは未達成。インターネットつながないのは、短期的な成果よりもすこし落ち着いて勉強しないと、というのもあるので、個人でなにか作るのは来年がんばります。

Framework Design Guidelines を (半分まで) 読んだ 12:46

2010/06/12 12:46

Microsoft の人々が .NET のライブラリを作る際にこんなことを考えて作ったんですよ、という "Framework Design Guidelines" (邦訳も『.NETのクラスライブリ設計』という名前で出ている) という本があり、それをずっと読んでいる。やっと半分まで来たんだけど、ここまででも十分に良い本だった。

最初 (1.1.4 にある Chris Sells の注) から

Please don't innovate in library design. Make the API to your library as boring as possible. You want the functionality to be interesting, not the API.

と、しびれる。ほんとねー、おれは最近の DSL ブームはねえ、ってそれはいまはいいや。

本自体は "Property Design" みたいな個々の細かな話題について、議論があって、まとめで DO/CONSIDER/DO NOT/AVOID のどれかではじまる文章の箇条書きで指針が示される、というかたちになっている。フレームワークといっても、論調はふつうのプログラミングの指針と大きな差異はない。ただ 2.2.1 では

The problem is that most design methodologies (including most commonly used object-oriented design methodologies) are optimized for the maintainability of the resulting implementation, not for usability of the resulting API.

なので、そういうのは、でかいフレームワークの API 層の design には向かないよ、と主張されている。

.NET 固有のこともいくつかでてくるけど Java, Scala みたいな親戚や、Perl, Python, Ruby みたいなスクリプト言語でも、クラスがあってインターフェースがあって例外があって、みたいなところで共通部分は多い。そういう言語をつかってプログラミングをしているひとなら、学べる部分はかなりあると思う。私は最近スクリプト言語を書くことが多いので、感心したり、自分のつかっている言語の語彙の貧弱さを残念がったりしている。

注釈

ちょっと珍しいのが記名の注釈が多いところで、地の文での議論に対して "Krzysztof Cwalina" みたいな名前付きで、補ったり、反論したり、注釈どうしで盛り上がったりするところがたまにある。

例えば、3.5 Names of Class, Structs, and Interfaces では Krzysztof Cwalina の「インターフェースに "I" がついてるのがあるけど、あれは歴史的事情で、いま考えるとやんなくてよかったよ。」という注に「COM とか Java からきたんだよね "I" つけるの。慣れてる人も多いし。」「個人的には好きだよ。」「ハンガリアン記法の応用だよね。」「System._AppDomain はまずったわー。AppDomain が implements してるんだから IAppDomain にすべき。」「HttpSessionState も IHttpSessionState あるとおもうと違うんだよねえ。」と、なんていうんですか、bikeshed で社内 Wiki 炎上みたいな、ガイドラインとしては見解統一しようよと思いつつも、読む分には面白い。

4.3 Choosing Between Class and Interface でも Chris Anderson が「.NET やったときは、なんというか、COM の複雑さ厳格さに反動がきててねえ、インターフェースも GUID も variant もIDL も、全部だめなものにみえててさ。いまならもうちょっと中立的な目でみれると思うんだけど。」と突然の告白がはじまっていて笑ってしまう。

まとめ

というわけで "Framework Design Guidelines" (『.NETのクラスライブリ設計』) はおすすめだよという話でした。DVD の内容は Web からもダウンロード できます。

Globalization 12:22

2010/06/12 12:22

NHK の番組が文庫本になった『ワーキングプア 日本を蝕む病』『ワーキングプア 解決への道』を読んだ。前者では国内の問題が、後者では海外や日本での対策が取材されている。

2, 3の不幸が重なっただけで乗り越えられない格差の下へ落ちてしまうのは恐怖だし、アメリカやイギリス、日本の一部での対策をみると、政府や社会がなせる部分もあるのだろう。

ただ、問題の一部は

  • 発展途上国の人々は先進国のような暮らしをもとめ
  • 企業は安い労働力をもとめ
  • 消費者は低価格で高品質のものをもとめ

というながれのなかで不可避に進むもののようにも思う。どこかで悪人が搾取してるので、それをやっつけて解決、って種類のはなしではないだろう。

コンピュータ関連業の場合

「解決への道」のアメリカの事例では、開発部門がインドに移転されてクビになり、ファーストフード店で働く元プログラマーがでてくる。ホワイトカラーだって安全じゃないぜ、と。アメリカ IT 協会の理事は

  • 海外の労働力は、安いだけではなくて能力でも競争力をもっている
  • 企業は、国内のできない人々に研修をうけさせる余裕なんてない

という。

これは日本にもくるんだろうなあ。

むかしは、企画者というか発注者というか、仕事相手が英語できないから、日本語という特殊技能で生き残ることもできるのかと少し思っていた。でも、Twitter, iPhone, Android みたいな「日本なんてメッセージカタログの翻訳だけやってればいいよ」が、上から下まで日本人が日本人のために作ったものに対してちゃんと競争力を持っているのをみると、うーん。

May 11:59

2010/05/29 11:59

5月はプロバイダとの契約がないまま過ごした。iPhone から Web をみることはできるので「断線」はいいすぎだけど、MacBook とかちゃんとしたコンピュータからはインターネットにつなげない。

生活はだいぶ変わったと思う。読書と、部屋の片付けの時間は増えた。プログラミングには、正直いって不便なことも多いけど、環境設定のための設定のための設定、みたいな脱線と深追いは減った気がする。

大きめの調べものや git clone など、つなぐ必要があるときは公衆無線 LAN のある場所に出向いている。マクドナルドの無線 LAN は、契約はしたものの、店舗や席によって品質に差が大きい。家の近くのマクドナルドの不安定さは想定外だった。東新宿駅の近所のマクドナルドは良い。

マクドナルドをはなれると、新宿の BLUE SQUARE CAFE が

  • 無線が安定している
  • いい席があるか外から確認しやすい
  • ノートパソコン開いているひとが多くて浮かない

ので気に入っている。遠いので週末しか行けないけど、まあ、毎日必須ならふつうにプロバイダと契約すればいいわけで。

ただ、家からインターネットをあまり見ないようにしている、私の仕事はインターネット関係で、それはちょっと後ろめたい。自制心と集中力のなさを選択肢を減らすことでなんとかしようとしているだけで、インターネットが悪いとか嫌いとかではないんだけど。こうやってブログは書くわけだし。

blog.8-p.info加藤和良 の個人的なブログで、プログラミングのはなしが多めです。