たまにゃ〜まじめに書きますか（笑）*1

http://d.hatena.ne.jp/uno/20040416#1082092980
DbC(契約駆動開発)とxUnitのネタですね。基本的にこの二つが補完関係にあるのは事実ですが、技術云々で話を進めるといまいちわかりにくいので例を挙げてせつめいしませう

DbC：自分はこれ以外を受け取らないぞ！と宣言しているちょっとわがままな人
xUnit：相手がこれを受け取るとこう返すよね〜って期待している人

たとえばDbCに異常値を渡すとPre-Conditionで排除されますね。正常値を渡せばPost-Conditionに書かれている範囲できちんと出力されるはずだと。それを確認するのがxUnit
次なる問題はDbCのConditionはどういう風に作られるのか？
実際のところほとんどプログラミングの問題なんですけど、防衛的プログラミングの基本に従って、設計書から読み取れる”あり得る値の範囲”＝Pre-Conditionで、Pre-Conditionをクリアした結果の出力がPost-Conditionになるわけです（そんなの判ってるって？（ｗ）
で、実際には・・・
プログラムを作っていて、無意識の前提条件っていうのが有るんです。（それを意識するのが大変なんですけど）たとえば、JavaでDB接続してから呼び出されるメソッドはふつーはDB接続しているかなんてチェックしないですよね。でもこれは大事な前提条件。こういう細かい前提条件から・・・IDは数値だと思っていたのに文字が入っているなどの作っている途中で(゜o゜)ゲッ!!ってなる前提条件（ふつー無いよね(^^;）まで色々あるのがすべて前提条件です。
（ついき）
Zが理解可能かどうかよりもそれにかかるコストの問題を無視出来ないんですよ。実際に適用するときに比較的低コストでほどほどの効果と、高コストで抜群の効果を比べて、仕様を証明可能なモデル化をするよりもほどほど効果のあるところで止める戦術をとってるってだけです。
実際問題、あの手のモノを利用するのは開発コストよりバグの方が怖いところだけだと思いますよ。原発とか地下鉄の制御システムとか・・・
そういう意味でDbCを軽めに適用しておくのは間違いじゃないと思うんですけどね〜やっぱりIoCとの連携が気になる（笑）