2008-04-15 ペラルゴニウムは固い決意 [長年日記]
_ RSpec にますます期待する
私は Gerald M. Weinberg （通称 jerry）の著作が大好きである。
ワインバーグは、1956 年からソフトウエアコンサルタントをやっているというから、私からみたら大先輩にあたる人である。彼の文体はアメリカ人らしいジョークにあふれており、挿絵もぶったまげたものが多いので読んでいて楽しい。中でも『ライト、ついてますかー問題発見の人間学』は傑作である。この本は、タイトルにもあるように「問題」に関する本である。この本の挿絵はサイコーである。特に、「目をつぶって両足でピョン」は名文である（「問題」について深く考察する前に、「自分の知っている方法で問題を解こうとしてしまう心理」を指す）。
『ライトついてますか』は、コンピュータに限らず、あらゆる生活の知恵を生み出すと思う。私の母は生真面目で素直に考え込んでしまう性格なので、この本をプレゼントした。当時、私はスウェーデンに留学していて、話を詳しく聞いている時間をとることができなかったので、jerry に代わってもらおうとしたのである。「目をつぶって両足でピョン」じゃなくて、あなたの問題を再考察してほしい、そういう気持ちを込めた。
J('ー`)し : げんきですか、いまめーるしてます
(`Д) : はいはい、送った本読んで、考え方が根本から変わりましたか
J('ー`)し : ごめんね、なんか書いてあるから、さっぱりわからないの、なんか重たいの、ごめんね
(`Д) : じゃあ、この前の悩み事は解決しましたか
J('ー`)し : 心配させたわね、それはどうでもよかったの
ライトがついていなかったのは私であった。
さて、ワインバーグのもう一つの著作、『要求仕様の探検学ー設計に先立つ品質の作り込み』を紹介しよう。この本は、大きく分けて二つのパートから分けられる：要求仕様の定義をどのようにするか、と、会議の仕方についてである。会議の仕方も工夫が凝らされていて面白いのだが、テストについて考える際に必要な「要求仕様」に関する考察が深い。本書にある quotations を 2 つ紹介する：
There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
In preparing for battle I have always found that plans are useless, but planning is indispensable. -- Dweight D. Eisenhower
アイゼンハワーの言葉をテストにあてはめればこうなる：「あらゆるテストには価値がない：が、テストすることは絶対必要である」 私はこれは真実をついていると思う。前にも何度か述べているが、テストはソフトウエアの品質を保証するものではない。テストはソフトウエアのバグを発見する為の heuristic な手法のひとつにすぎない。
『要求仕様の探検学ー設計に先立つ品質の作り込み』の最後の章は、「要求定義のプロセスをいつ終わればよいだろうか」という問いについて述べている。要求定義のプロセスに終わりはない。同様に、テストケースを作成することも終わりがない。では、どうすればよいのか。ワインバーグの解は本に書いてあるし、私自身もそれなりに答を持っている。終わりがないが、テストケースを作ることは楽しいし、テストに通ったときはもっと楽しい。
[04/11/08 PHD Comics : Celebratory Danceより引用]
先日、かくたにさんの「スはスペックのス」を聞いた。この発表は、振舞駆動テスト(behavior driven testing)に基づく開発手法の紹介を目的としている。発表内容は、前半がオーム社営業マンで、後半がRSpec - Ruby における振舞駆動テストフレームワークのデモであった。このデモはすごかった。Emacs が RSpec にカスタマイズされている！
RSpec は私も出たてのときに、これはいいものだと感じた。当時、テストには共通言語がなくて、xUnit が流行り始めたときに assert_xxx というキーワードがでてきたのだけれど、これは単に assert() の variant にすぎなかった。RSpec はその点、「言語」であるので、要件を理解するための重要な道具となりえる。
RSpec は残念なことに、書き方が特殊である（そう思わない人もいるのかもしれないが）。以下に、かくたにさんともろはしさんの RSpec の紹介の文章があるので、興味をお持ちの方は見てみると良いと思う：
こういう良質の記事を毎号出しているるびまは偉い。編集者にはとても感謝している。
私見であるが、振舞駆動(behavior driven)という方法もあるが、もう一つ、期待駆動(expectation driven)という方法があるのではないか。要求仕様は、普通自然言語で書かれる。それをプログラムの振舞(behavior)として、コードに落とす方法は一通りではないし、しばしば難しいことが多い。オブジェクト指向だから、オブジェクトの振舞が気になるのであって、関数型プログラミングでは振舞という言葉は気にならない。むしろ、関数 f の input に対して、どのような output が期待されるか、ということがテストでは気になる。言葉の言い換えに過ぎないのかもしれないが、『要求仕様の探検学ー設計に先立つ品質の作り込み』では、ソフトウエアに対する「期待」について深い考察をしており(IV章：明確な期待)、テストに関しても同じことを考えることができる。振舞を制限するということにはためらいを覚えるが、一方、期待は制限される。なんでも望みが叶う訳ではない。プログラマはユーザのパパではない。同書によれば、制限される期待のパターンは次の 3 種類である。
- P : Possibility (今、実施する)
- D : Deffered (後の版で実施する)
- A : Absolute imposibility (考慮から除く)
[『要求仕様の探検学ー設計に先立つ品質の作り込み』Donald C. Gause and Gerald M. Weinberg, p.231より引用]
テストを以上の 3 種類に分けることによって、今書くべきテストを考え直すことができる。それ以外にも、振舞という言葉を期待という言葉に置き換えることによるメリットはあるのだが、所詮は言い換えにすぎないのだからどうでもよいことでもある。もし、興味を持たれたら、本書を手に取られると良いと思う。
かくたにさんの講演の終わりの質疑応答で、私は「テストには終わりがない、かくたにさんはどうしておられるのか」と聞いた。かくたにさんの答は明解であった。私は満足した。問いを持つものは、自らに問わねばならない。が、自らが得た直感はしばしば勘違いであるので、師に尋ねるという方法をとる。これが禅の本質である。
プログラマの手というのは、たいてい、親指を少し広げてしまう癖があるように見受けられる。手をホームポジションに置いてもらえるとわかるのだが、スペースキーに親指を弛緩して乗せているので、普段から親指と手のひらが空いているのである。これは、筆を持つ人とは対照的な特徴である。あなたが、プログラマでなければ、たとえば文庫本を読むときの手を想像してほしい。
かくたにさんとは、二度握手した。最初は、「はじめまして」、最後は「また会いましょう」という気持ちが込められていた。かくたにさんの手はプログラマの手であった。
追記：Chiphead さんのCinecaption:しねきゃぷしょんフォントを使ってみることにします。このフォントを使用するにあたって、「雑誌掲載については、事前にメールを差しあげる」というルールには少し敏感にならないといけないね。
