>>639

＞で、呼び出される側のオブジェクトの状態によって、呼び出し順序が変わらないように
＞するのがテストしやすい構造なのではないかと。

でも、それって（そういう構造に）実装するという実装の問題ではなくて、
実現する（要求される）機能によって決まっちゃうと思うけど。。。

大昔の本「Microsoft Code Complete」にもあったけど、Excelの再計算
処理を実現するとき、全体を計算しなおすと確実だけど効率が悪い。
部分的な計算だけで済ませば速いけど、バグが生じやすい。だから
Microsoftの技術者は常に両者の結果が一致するかのチェックルーチン
を組み込んで部分的な計算ルーチンのデバッグをした。といった話
が書かれている。

俺もそれをイメージしていまレスを書いてるんだけど。俺も似たようなことはする。
パフォーマンスをチューニングする時に馬鹿正直に書いた処理といろいろ小技を
使った処理を同時に動かして、プログラム自身でチェックさせる。

＞そこまでして、その部分のテストを重要視していることが示せていいんじゃないかなと。
＞屁理屈かもしれないけど。

というとXXとXXRecorderの状態遷移が見かけ上一致するか否かのテストもするって
こと？まあ、そこまでするのであればそれはそれで一理ある。でもこれはテストのための
テストだよね。

＞条件付コンパイルは、その中に副作用を紛れ込ませたときに恐いので、テスト環境では
＞使用したくないな。

副作用があるかないかをテストすべきでと思うけど。それがテストのためのテスト
ってことでいやなのかな。ま、それはそれで共感する部分もある。俺も条件付コン
パイルはあまり多用したくない。

けどどの方法を使うにしろ上に書いたようにテストのためのテストは避けられないと
思うけど。

＞パフォーマンスの関係も、もちろんあるんだけど、例えば、テストのためだけに、
＞隠蔽されている内部構造を取得できるGetterを付けてもいいかとか、そんな感じ。

というわけで俺はGetterをつけるべきと思う。例えば電気回路にもテスト用のピン
が出てるよね。