平鍋です．
Toru TAKAHASHI wrote:
> "Test Infected: Programmers Love Writing Tests"
> Kent Beck, Erich Gamma
> http://members.pingnet.ch/gamma/junit.htm
> ですね。
ありがとうございます．
> JUnitでのテストの解説が詳しく書かれています。先週末から読み始めて
> いますが、まだまだ1/3程度しか進んでいません。しかし、読めばテスト
> したくなります。
> 前にプロジェクトで作業ルールとして各パッケージの設計時には必ず
> テスト項目を記述するように規定しました。しかし、実際には形骸化
> してしまいほとんど機能しませんでした。
> 今回、JUnitを知って、これなら機能するのではないかと思っています。
そうなんですよね．小さいプロジェクトならまだしも，大きくなるとこう言った
ルールは形骸化する傾向にありますよね．
私の経験をすこし．
２年くらい前からフリーで公開している自作のベクトル・マトリクス演算の
クラスライブラリがありますが，テストメインを付けて公開しています．
テストメインは，main という関数の中に，適当なテストとassert を並べて書い
た
だけのものです．それでもテストで発見したバグは多くありました．
このようなスタイルはB.X.(Before XP)時代にも非常にたくさんの例がありま
す．
私がお手本にしたのは，Tools.h++ というコンテナ系のクラスライブラリが
持っていたテストスイートです．別の例として，gnu のコンパイラ等も，
ビルド後，"make test" としてテストケースを走らせることが可能です．
また，C++ のクラスライブラリ STL のフリーバージョン(STLport)のような
複雑なクラスライブラリのテストも，別プロジェクトで開発されたテスト
ケースが利用していました．
私も実プロジェクトで，Unit Test を強制するようなルールを作ったことがあり
ます
が，途中から Unit Test を書くのが辛くなります．理由は，
(1) 依存性が多くなる．自分のクラスのテストを書くのに，人のクラスを使わな
くては
ならないが，人のクラスにはテストがないので，自分もテストを書かない．
という悪循環に陥る．
(2) どうせ結合/統合/総合/機能テストをする．その時にテストされるはずだ．
と思う．
特にクラスライブラリのように製品のインターフェイスがプログラマである場合
Unit Test はかなり成功例があります．それは，Unit Test ~= Function Test
だから，Unit Test に大きな価値がある場合です．またクラスライブラリはサイ
ズ
が大きくならないので，結局(1)と(2)をクリアできます．
実プロジェクトでも，(1),(2)をXPとKentBeck のテスティングフレームワークに
よって
解決できる可能性がありますね．
以上