実例による仕様書 - Martin Fowler's Bliki (ja)

http://martinfowler.com/bliki/SpecificationByExample.html

XP/Agile Universe 2002のワークショップで「Specification By Example（実例による仕様書、SbE）」という言葉に心を奪われた。これは、XPにおけるテストのあり方のひとつではないか。

（このところ、テスト駆動開発(TDD)のテスト部分を語るのは流行遅れなのだそうだ。ひどい話だ。Jonと同じく、私も、そんな副次的なものなんかよりも包括的な自動テストにこそTDDの真髄があると考えている。例えば、誰かに「100万ドルあげるから山にハイキングしておいで」と言われたとしよう。私は胸を張ってこう言うね。「今回のハイキングの目的は、自然の美を堪能するためである」と。いや、まあ、もちろん、懐もあたたかくなるけど……ね。）

仕様書について議論する際、SbEという考えは今まで出てこなかった。仕様書とは、システム全体を網羅するものである。しかし、実例は部分的にしかフォーカスしない。そのため、そこから全体を推測しなくてはならない。SbEだけで要求定義は出来ないように思う。だが、要求定義における主役級の技術に成り得るかもしれない。

これまでは厳密な仕様書があり、事前／事後条件でもって、「成功した」「失敗した」という判定を明確に下すことができた。そして、こういった技術が一般的でもあった。これは契約による設計(DbC)にも適用されている。こういった技術が現在幅を利かせてはいるが、これが理想的だとはいえないだろう。事前／事後条件を使った方が簡単な状況もあるだろうが、むちゃくちゃトリッキーになってしまうこともあるのだ。私はこれまでいくつかのエンタープライズアプリケーションで使おうとしたことがあるが、事前／事後条件を書くのはソリューションを記述するのと同じくらい難しいように思った。 SbEのグレートなところは、書くのがとても簡単だという点だ。我々がソフトウェアを提供する非ナードだって書けてしまう。（ Timothy Buddがこう指摘している。「スタックの振る舞いの多くは事前／事後条件という形で示すことができるけど、（スタックが）後入れ先出し(LIFO)になっていることがわかるように事前／事後条件を書こうとすると、相当トリッキーな仕事になっちゃうよね」。）

TDDのテストで重要なのは、二重チェックが入っているというところだ。これはXPコミュニティのちょっとした「嘘」でもある。 XPコミュニティは「一度、たった一度だけ(Once and Only Once)」と強調しているが、実際は、コードでチェックして、テストでチェック……と、2回やってるのだ。

Kentはこう指摘していた。「二重チェックの原則は重要である。人間が常に行っている原則である」。二重チェックの肝は、チェックごとに違ったアプローチをとるというところにある。 SbEとコードによるチェックというような全く違った2つのものを組み合わせれば、君のエラー発見能力はきっと向上するはずだ。

形式仕様書のコミュニティでは、設計が仕様書を満たしているかどうか検証する術がないという問題を絶えず抱えていた。エラーを犯してしまうのは人間であるため、人間抜きに検証できないかと考えている。これ、SbEを使えば簡単。これが SbE のもうひとつの側面である。理論的には役に立たないように思えるが、実は大変役に立つのである。

あるDbCファンがこう指摘していた。テストという観点から仕様書を書くとなれば、実装側は仕様を満たすために、特定の入力に対する応答をハードコードするだけでよくなってしまうじゃないか、と(訳注：例えば足し算の実装の場合、テストケースに「1+1」を設定したときに、単に2と返すコードを作ればいいのか（んなわきゃない）、というイメージ)。そうねえ、そうかもしれないねえ、どうだろうねえ。でも、このこと自体はそれほど問題じゃあない。ただし、重要なポイントがある。テストでは不完全なことが往々にしてあるのだ。だから常に「代替案」を用意おかなければならない。私のような天邪鬼は、これを「プラス」と考えている。 SbE は明らかに十分じゃないのだから、すべてがまるっと伝わっているか確認しなきゃいかんのは当然じゃないか。昔ながらの要求仕様書で一番危なっかしいのは、「仕様書に書いてるから読んでるだろう」と考えてしまうことである。

SbEは、みなが協調しており、ケンカなどしてない状況下でのみ有効である。実例は設計チームのアイデアの引き金となる。しかも、地に足のついたアイデアである。他にもまだやることはある。通常の会話、Domain Driven Design のような技術、DbCだって必要になるだろう。私はDbC（またはEiffel）を完璧に行う機会がなかったが、いつも契約通りにインターフェイスは作っている(訳注：DbCの「契約」と取引の「契約」が掛かっている……が、日本語にすると何が何やら)。 SbEは強力なツールである。おそらく私が一番よく使ってるものかもしれないなあ。でも、唯一のツールというわけではない。

（ SbE に関してもうちょっと考えたい方へ。Brian Marick の書いたものを読んで欲しい（SbEという名前じゃないけど）。彼のサイトのどこかに、彼なりの意見をまとめたページがあるはずだ。もちろん、そのまとめページを探すよりも、全部読んじゃったほうがいいんだけど。）

[[kdmsnr]] ありがとうございます。プロパティって何？って思ってました…(^^;; *2004-10-28 (木) 16:13:06 ‘’[[keis]]’’ : お疲れ様です。Timothy Budd の指摘のところを、ちょっと変えてみました。