wildcatsの日記

赤羽在住でIT関係の会社の社長やってます。

Re:テストとか

Test

さかたさんからＴバックがもらえたので調子に乗って書いてみる(^^;


ただ，一般的に「どうやって」処理するかに相当するものは要件として書くのですか？
「どうやって」処理をするかは要件レベルでは書かないです。
ここの

8の倍数を用いるとものすごく早いアルゴリズムを使うというのが要件であり
と書きましたがここもブラックボックステスト的には誤りで(^^;;;
# すんませんすんません。
「8の倍数を使うと高速に処理が完了する」がブラックボックステストの
テスト対象部分になるのではないかと思います。
# アルゴリズムには着目しない。

ホワイトボックステストとして機械的にテスト項目を挙げていくと，逆に要件/仕様のあいまいな点抜けている点が明確になるかもしれません．
うーん。。。この部分は少し良くわからない部分です。

「DbCで定義した事前条件を満たさない呼び出しを正しく例外などとして扱うか」のテストはいらないのでしょうか?
ここでMeyerのオブジェクト指向入門の一説を引用します。
P.196

完全な世界では実行時チェックは必要ない。私たちは全てのクラスが正しいかどうかを理解しているので、原則としては、システムが正しいこと（すなわち、すべてのクラスが正しく、全ての呼び出しが事前条件を満たしていること）を証明できるはずである。
理想的なコンパイラというものがあったら、そのコンパイラはこのような仕事を実行するプログラムチェッカの機能を備えているだろう。
よって事前条件を満たさない呼び出しはコンパイラで弾くのが理想的であり
実行時の挙動としては必ずしも例外としなくても良いと思います。
事前条件を満たさない呼び出しには例えば無限ループが発生してもVMがクラッシュしても
呼び出し側の顧客クラスに何も保証する必要は無いと思います。
追記：続きを引用します。

残念なことに、私たちはそのような目標とはかけ離れたところに生きている。
これを実現するためには、プログラミング言語の意味を形式的に定義する手段と実用的なツールが必要である。
しかし、それは現在のプログラム証明技術を超えたものである。
ということでEiffelには実行時に表明を監視するオプションがあります。
# う〓む。。。id:koichikさんお勧めの７章は本当に深い。
Javaだと
http://www.javaworld.com/javaworld/jw-02-2002/jw-0215-dbcproxy-p3.html
このあたりでしょうか。