渡辺さん，こんにちは．寺田です．
> つまり、その関数が、1.0e-4以内で成り立つと定義するなら、その範囲内なら
> OKです。
その「1.0e-4以内で成り立つと定義する」ことが難しいんですよね．
例えば，「1.0e-20以内で成り立つと定義」しても，そのような実装は不可能か
もしれません．逆に，「1.0e-1以内で成り立つと定義」すると，実装は出来ても
使い物にならないかもしれません．
結局，厳密なテストは諦めて，平鍋さんの仰るように安全側に倒したテストでア
ルゴリズムの妥当性を検証するに留めるしかなさそうです．
> 「ある回数以内にあらかじめ決められた誤差範囲内に収束しない場合、XXXを返す。」
> と定義するのであればそのテストを書けばよいでしょう。
了解です．つまり，(a)明らかに収束するはずの関数 と，(b)明らかに発散する
はずの関数 の２つをテスト用に用意し，その両方で期待通りの結果が得られる
ことを確認するテストをすれば良いわけですね．
結局，ユニットテストではあらゆる関数形をカバーするようなテストはしなくて
も良い，ということですよね．
> 異常時の動作を定義するのは大変です。
> また、動作を保証するのに必要十分なテストの代表値を決めるのも大変です。
> それらはやはり人間がやらなければならないと思います。
そうですね，これが本当に大変だと思っています．
十分丁寧に作りこんだつもりでいても，全く予想だにしない形状が入力されて計
算に失敗してしまうことが多々ありますね．
〜〜〜
XP では，ユニットテストを作ることによってリファクタリングを実行しやすく
なると主張していますよね．曰く，ソースを書き換えてもテストをすれば前と同
じように動作することが確認できる，と．
しかし，所詮ユニットテストではあらゆるパターンをカバーできないとするなら，
ユニットテストは本当にリファクタリングに躊躇う我々の背中を押してくれるも
のになり得るのか，と疑問を抱いてしまいます．
まあ考えてみれば，オブジェクト指向設計と計算アルゴリズムの組立ては全く別
次元の話ですから，「計算アルゴリズムのリファクタリング」みたいなものの援
助をユニットテストに期待するのは，全くのお門違いなんでしょうね．
＃勝手に自己完結してしまった・・・．
以上です．
--
Y.Terada <terada@....jp>