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