平鍋です．
On Wed, 12 Mar 2003 23:07:44 +0900,
"Y.Terada" <terada@....jp> said:
> やっぱりそうですよね．
> でも，そういうプログラムでも，コード中に幾つかの assert 文を埋め込んでい
> くことはある程度は可能ですよね．例えば，この値は正でなくてはおかしいとか，
> この範囲に収まっていないとダメだ，などという程度なら．
> 実コードの内部に埋め込む assert 文は，
> ・private メソッドもテストできる
> ・関数内のローカル変数や private 変数にもアクセスできる
> ・関数の先頭/末尾だけでなく，計算の途中に埋め込むことが出来る
> というユニットテストにはない特徴があります．この特徴は，力学シミュレータ
> や幾何計算のようなプログラムのテスト（というより簡単なチェックに過ぎませ
> んが）には必須なものではないかと感じています．この辺にユニットテストの限
> 界を感じます．
私は，アルゴリズムのチェックのためにプログラムの中に埋め込ん
で行くタイプの assert を(個人的に)，
・内部表明
と呼び，ユニットテストのように，プログラムの外から assert す
るものを，
・外部表明
と呼んでいます．
内部表明は，例えば古典的にはループ不変表明などがあり，
■ Jon Louis Bentley,Programming Pearls:,Addison
Wesley Publishing Company,1988,ISBN 0201118890
訳:野下浩平,プログラマ設計の着想,近代科学社,1989, ISBN 4-7649-0158-7
■ Jon Louis Bentley,More Programming Pearls:Confessions of a Coder,Addison
Wesley Publishing Company,1988,ISBN 0201118890
訳:野下浩平/古郡廷治,プログラマのうちあけ話−続・プログラム設計の着想,近代科
学社,1991,ISBN 4764901773
らに，読みやすく出ています．また，Bertlan Meyer の DbC(Design by
Contract)，および Eiffel の requre/ensure/invariant は内部表
明が進化したもの，あるいは，内部表明がメソッドやクラスの境界
に上って行って，実行時チェック可能かつセマンティックな仕様記
述に発展した，と言った方が良いかもしれません．
歴史的な進化としては，
内部表明 -> DbC -> 外部表明
となりますが，現在でも，内部表明が有効として知られてる分野
に，「アルゴリズム」，「OS」，「マルチスレッド」が，あると思
います．複雑な数値計算以外にも，OS やマルチスレッドの分野
は，assert 無しでコーディング/デバッグするのが非常に難しいでしょう．
内部表明は，プログラムの読み手に対して書き手の意図を補強する
意味もありますね(これは外部もそうですが)．昔，Solaris のマル
チスレッドライブラリを見ていて，ロックに関するassert を静的
に分析する lintツール(lock_lint)というのを見て感動したことが
あります．これも，意図を内部表明としてコードに埋め込む利点．
私が感じているのは，多くの内部 assert は，メソッドを細かく分
割することで，外部表明に移行することが可能だいうことです．
現在は，ユニットテストの流行によってこの傾向が進んで来てい
る．ただし，うまく分割できないものは，やはり残るのではない
か，と思っています．それの代表例が先に上げた3つの分野です．
以上