石井です．
> 実は、この話には、おちがあります。プログラムを読みたくない方は、ここで、「
> ここまで」をサーチして、そこからお読み下さい。
すみません，読みたくないっていうわけじゃありませんが，プログラム
読んでません(^^;．
> 結局、Test First Programming は、凄いというつもりが言えなくなってしまいま
し
> た。print文に頼らざるえなくなったのは、以下の理由からかと思っています。
print文のデバッグは，僕も結構やってますし，そんなに気にしてませんよ．
> 1.乗ってくるとテストを書かなくなる。20分ぐらい、テストなしで
> コードをかいていますね。これは、ペアプログラミングをしていれば、相方が
> 注意してくれたでしょうか？
僕の場合，Unit Test 書き始めのころのコードを見ると，テストが甘く
もっとTest First を徹底しておけばよかったと思うことが多いです．
後からテストコードを追加するという作業はかなりつらいです．
ペアでないとくじけそうになります．一度痛い目を見ないと，テストを
先に書くという習慣はつかないかもしれません．
> 2.コンパイルを通すために芋づる的にどんどんコードだけを書いてしまう
> ような気がします。中身のないメソッド、例えば、return null だけのメソッド、
> を書いてコンパイルを通すような事をもっと行うべきか？
これはテストをテストするために必要ですね．テストコードが正しいかどうか
を検証するには，わざとエラーを出すようにしてみるのが手っ取り早いです．
それと，一旦テストが通ったらリファクタリングできないか考える習慣も
つける必要があると思います．
> 3.メソッドがprivateだったため、テストを怠ったところがありました。
> SummarizerのsummarizeとfindSumは、テストが必要だったでしょう。
private もテストすべきという立場と public だけで十分という立場があるよう
ですが，これは，一般論で考えるより，private でもそのメソッドが失敗
しそうならテストすべき，と思うほうが現実的じゃないかと思います．
private まで徹底的にテストすると，リファクタリングするときに困るし．
> 4.それから、今回、問題の根源であったSummarizerTestHelperのisEqualは、
> publicでは、ありましたが、テストのヘルパーという位置付けのため、テスト
> をする事を全く考えていませんでした。
こっちも上と同じかな．
Test First Programming がすごい，というのではなくて実際にはテストを先に
書かないとテストが甘くなる，または書かない，というのが本当のところだと思
います．
では．