Example(実例による仕様書、SbE)」という言葉に心を奪われた。これは、XPにおけるテストのあり方のひとつではないか。(このところ、テスト駆動開発(TDD)のテスト部分を語るのは流行遅れなのだそうだ。Jonと同じく、私も、そんな副次的なものなんかよりも包括的な自動テストにこそTDDの真髄があると考えている。誰かに「100万ドルあげるから山にハイキングしておいで」と言われたとしよう。私は胸を張ってこう言うね。「今回のハイキングの目的は、自然の美を堪能するためである」と。いや、まあ、もちろん、懐もあたたかくなるけど......ね。)仕様書について議論する際、SbEという考えは今まで出てこなかった。仕様書とは、システム全体を網羅するものである。実例は部分的にしかフォーカスしない。そのため、そこから全体を推測しなくてはならない。SbEだけで要求定義は出来ないように思う。要求定義における主役級の技術に成り得るかもしれない。これまでは厳密な仕様書があり、事前/事後条件でもって、「成功した」「失敗した」という判定を明確に下すことができた。いった技術が一般的でもあった。これは契約による設計(DbC)にも適用されている。いった技術が現在幅を利かせてはいるが、これが理想的だとはいえないだろう。トリッキーになってしまうこともあるのだ。事前/事後条件を書くのはソリューションを記述するのと同じくらい難しいように思った。SbEのグレートなところは、書くのがとても簡単だという点だ。我々がソフトウェアを提供する非ナードだって書けてしまう。Buddがこう指摘している。スタックの振る舞いの多くは事前/事後条件という形で示すことができるけど、(スタックが)後入れ先出し(LIFO)になっていることがわかるように事前/事後条件を書こうとすると、相当トリッキーな仕事になっちゃうよね」。)TDDのテストで重要なのは、二重チェックが入っているというところだ。これはXPコミュニティのちょっとした「嘘」でもある。実際は、コードでチェックして、テストでチェック......と、2回やってるのだ。Kentはこう指摘していた。「二重チェックの原則は重要である。人間が常に行っている原則である」。二重チェックの肝は、チェックごとに違ったアプローチをとるというところにある。君のエラー発見能力はきっと向上するはずだ。設計が仕様書を満たしているかどうか検証する術がないという問題を絶えず抱えていた。エラーを犯してしまうのは人間であるため、人間抜きに検証できないかと考えている。これ、SbEを使えば簡単。理論的には役に立たないように思えるが、実は大変役に立つのである。あるDbCファンがこう指摘していた。実装側は仕様を満たすために、特定の入力に対する応答をハードコードするだけでよくなってしまうじゃないか、と(訳注:例えば足し算の実装の場合、テストケースに「1+1」を設定したときに、単に2と返すコードを作ればいいのか(んなわきゃない)、というイメージ)。しれないねえ、どうだろうねえ。このこと自体はそれほど問題じゃあない。重要なポイントがある。テストでは不完全なことが往々にしてあるのだ。常に「代替案」を用意おかなければならない。私のような天邪鬼は、これを「プラス」と考えている。明らかに十分じゃないのだから、すべてがまるっと伝わっているか確認しなきゃいかんのは当然じゃないか。「仕様書に書いてるから読んでるだろう」と考えてしまうことである。SbEは、みなが協調しており、ケンカなどしてない状況下でのみ有効である。実例は設計チームのアイデアの引き金となる。地に足のついたアイデアである。他にもまだやることはある。ような技術、DbCだって必要になるだろう。いつも契約通りにインターフェイスは作っている(訳注:DbCの「契約」と取引の「契約」が掛かっている......が、日本語にすると何が何やら)。SbEは強力なツールである。私が一番よく使ってるものかもしれないなあ。唯一のツールというわけではない。関してもうちょっと考えたい方へ。書いたものを読んで欲しい(SbEという名前じゃないけど)。彼のサイトのどこかに、彼なりの意見をまとめたページがあるはずだ。そのまとめページを探すよりも、全部読んじゃったほうがいいんだけど。ありがとうございます。指摘のところを、ちょっと変えてみました。gmail.combliki-ja。