寺田です．
> > 歴史的な進化としては，
> >
> > 内部表明 -> DbC -> 外部表明
> >
> > となりますが，
>
> これ、面白いですね。表明は、
>
> ・人間（プログラマ）が読むため、
> ・コンピュータ（処理系）読むため、
>
> という2つの役割があると思いますが、
> 内部表明と外部表明の違いは、人間・コンピュータをさらに分割していますね。
> クラスの「開発者」と「利用者」の二つに。
なるほど・・・！ これは面白いです．
クラスをブラックボックスとして使用する「利用者」にとってみれば，テストは
ユニットテストによる「外部表明」で OK ですね．そして，その「外部表明」を
満足するように開発する「開発者」は，その開発過程において「内部表明」を用
いる，ということですね．
アルゴリズム系は，外部からみた仕様は非常に単純なのに，それを実現するアル
ゴリズムは非常に複雑，ということが多々あります．従って，実装には内部表明
の助けを得る必要が出てくるようです．
お陰で自分の感じていることが少し整理できた気がします．少なくとも，アルゴ
リズムの実装には自信を持って内部表明が使えそうです．今までは上手くユニッ
トテストできないことに悩んでいましたが．
平鍋さんにご紹介いただいた本も，機会があれば読んでみたいと思います．
ところで，，，
ユニットテストとは違いますが，内部表明でも，XP の test a little, code a
little, ... のリズムは応用できると思っています．最近の私のコーディングリ
ズムは，
assert a little, code a little, ...
という感じです．いまいちユニットテストもテストファーストも使い切れていま
せんが，assert first (?) は結構使います．
１．まず存在しないメソッド f() をコールする
→ コンパイルエラー
２．空の f() を作成する． f() { assert( false ) ; }
→ assert() で落ちるのを確認
３．assert() を随所に埋め込みながら実装/実行を繰り返す
っていう感じです．
ユニットテストじゃないので XP とは言えませんが，XP の精神は取り入れられ
ていると思っているのですが・・・．如何でしょうか？
--
Y.Terada <terada@....jp>