ユニットテストの問題を考える前に、ユニットテストが好きな人たちの、ステレオタイプみたいなもんを、独断と偏見で考える。
こういう人は、アジャイル大好きで、ＴＤＤを主張する人たちだ。とすると。。
当然のように、こういう人たちは、ＤｂＣ（契約による設計）を主張する。
この場合、事前条件、事後条件、不変条件をアサーションとして入れて、ユニットテストのテストツールで、その条件がクリアすると、青くなるから（すげーひょーげんだ ＾＾；）青くすることが目的となる。（言ってる意味がわかんなかったら、こんなところを見てください）
で、事前条件、事後条件、不変条件を、アサーションの形に落とし込むには、実質、事前条件、事後条件、不変条件の命題を、同値条件（さらには、境界値）にまとめ、それを、アサーションの条件として入れることになる（さらにテストケースを縮退することもありえるが）。
そうすると、結果的に、同値条件を、どこから抽出してくるか？ということが問題になる。
これは、ＤｂＣのスタートラインから考えると、当然、仕様書からになる。
仕様書に、事前条件、事後条件、不変条件があるのだから。
ということは、仕様書に書かれていない条件は、テストできないということになる。
もし、ソフトウエアの開発上、仕様書に書かれていない条件というのが、「当然のごとく」、「日常的に」、「論理的に」入ってくるのであれば、この考え方は、崩壊してしまう。
ところが、ウィリアムのいたずらが指摘するまでもなく、このような仕様書に書かれていない条件などというのは、「当然のごとく」、「日常的に」、「論理的に」（＝ソフトウエア業界の構造的に）入ってくる。
なぜか。。。
ソフトウエア業界の構造として、コンサルやエラーい人（一次請け、二次請けのＳＥ）、給料の高い人は、現在の、実機の問題点を知っている人でなく、コンサルティング会社、または、いい会社の偉い地位に居る人、あるいは下請けの社長や取締役で、人集め中心の人である。
その人たちは、ハードや技術に詳しいというよりか、むしろ、戦略や業務に詳しい、あるいは、ご機嫌取りや、権謀術数、人集めに詳しい人である。
その人たちが書く仕様書は、技術的な問題点については触れていない。
あるいは、あるハードや特定の技術にむちゃくちゃ詳しい、論を張るような人たち。この場合、詳しい業務分析方法や、現実的な落とし込み能力がなかったりする（なんでもＤＢに入れたり、なんでもユビキタス ＾＾）。
この場合、業務が抜けていたりする。
つまり、今のソフトウエア業界の構造上、仕様を書くえらい人は、技術上の問題と業務の両方を熟知している人というよりは、「昔」そういう人だったかもしれないけど、いまは、業務よりか、スペシャリストの人が担当しちゃったりする。
そーすると、とーぜん、自分の知らないところの仕様は抜ける。
そーすると、その部分は、事前条件、不変条件に載らないので、ユニットテストから外れる
そーすると、その部分でバグになるということだ。
たとえば、「ある時間ぴったしに」何かのバグが起こるといったとき、業務系しかやったことのない人は、「境界値チェックをしてないんだろう」とかいう。この一言を言ったとたんに「こいつ、知らないのか・・・」といって、以降の部下からの信頼度０になってしまったりする危険もある。
プロセッサが２つ動いている場合、ある時間ぴったしには、反応しないことがある。
電圧が、その瞬間に、そこまで上がらないことがあるから。。
（通信が届かないとかもある）
そこで、遊びを設けないといけないことがあるんだけど、その遊びが、チューニングとなる。
なので、境界値ぴったしになんかになると、困ったチャンになることがある。
（ちなみに、これが、前のICameraで、「寝かせる」とか書いているところにあたる。これは、カメラのコプロと、本体のＣＰＵとの関係で起こるようだ。なので、コプロを使わない場合、連写の問題が起こらなかったりする。起こらないメーカーと、起こるメーカーは。。ひ・み・つ）
ということで、構造的に、仕様書に抜けは、ばりばりあり（つーか矛盾も多いし、最近の仕様は。。つーか、仕様をまとめる力のないやつが、アジャイルでごまかしてるっていうケースもあるし）、ということで、仕様書を信じてユニットテストをしても、テスト的には、問題になり、それが、結合で分かればいいんだけど、システムテストにきて、どーしょーもならなくなる。。
じゃあ、どーするのか。。っていうところで、それを書いたサイトをみつけたんで、今回は、そのサイトを紹介しようと思って、ここまで、前置きを書いたんだけど。。
前置きだけで長くなりすぎたので、今日は、ここまで。
覚えていたら、続き（どーするのか。。っていうことを書いたサイト紹介）を書きますね
アクセス
トータル
ランキング
