なひです。
> From: Eiji Yamane [mailto:e-yamane@....jp]
> Sent: Friday, August 02, 2002 1:26 AM
> ＃と言うわけで、なひさんの考えで私は前科数十犯です。
ちなみになひも、公開しているRubyのコードに関しては
同様です。^^; 用途に応じて適切に余力を振り向ければ
よいのだと思います。
> ＃上位に返却するのもなんか気に入らないので、大抵
> ＃RuntimeExceptionでかぶせてしまいます。
元の話とは違いますが、なひはこういうときは気にせず
投げ上げて（結果的にもしそれが起こったらアプリがクラッシュする）
しまいます。起こらないはずのものが起こったら、
それが明示的にわかったほうがいいので。
> 「でも、他にもっとやるべきことないですか？」
> 僕の主張は徹頭徹尾それだけです。
他にやるべきことがありそうなら、そちらを優先すべきですね。^^;
> > 「XPのプラクティス（の一部）を『遵守』できているかどうか」
> > を測る指針として考えるとどうでしょうか。
> > カバレジはよい指針になりそうな気がしませんか。
> おっしゃる通りだと思います。
>
> が、プラクティス自体を『遵守』すること自体に
> あまり重きを置いていないのです。
>
> 早く、高品質とメンバーが自信を持って言えるシステムを
> 構築できさえすればそれでよいので、
> 「XP的ではない！」と言われることとかはあまり気にはしません。
御意。いろいろなやり方があると思います。用途に合わせて
方法論を適切に変化させ続けるべきでしょう。
> 予想しきれないことも多いでしょうと言う点は確かにあると思います。
> が、予想出来た場合は、事前条件として、「@precondition i != 0」と言う
> キーワードを入れておけば、それは呼び出し側の責務違反ですから、
> *Foo*としてテストする必要はないと僕は思います。
> 同様に、nullが渡ってくると困る場合も、
> 大抵「@precondition param != null」とか、
> 書いてごまかします。
テスト不要の件、同感です。元の説明が悪いですね。前回の例は、
* あるプログラマーが、
* テストファースト時に、
* Foo#rateFor100の仕様として、i == 0のときに
Exceptionを返すよ、という手抜き仕様を考えた
場合の例でした。
事前条件としてi != 0という仕様の場合、テストすべきは
Foo#rateFor100ではなく、これを呼び出している例えば
Bar#createReportなどで、「Foo#rateFor100を呼び出すときに
絶対に0を渡さないこと」をテストする必要がありますね。
こうやって債務を外に追い出していって、債務を被開発対象の外、
顧客側の責任にできたら、テストは不要だと思います。
マニュアルに「web.xmlの中身には正しい名前を書いてください
（そうじゃなかったら何が起こっても知らないよ）」
とか書いておしまい。(^-^
> > 結局、よいテスターが頑張る、しかないのかなぁ。
> 個人的には、良いテスターが頑張るより、良いプログラマーが、
> コードを記述する段階でシンプルなデザインで、明らかに誤っていないと
> *思われる*コードを書いてくれるほうが嬉しいです。
そうですね。なひはその前提の基に、さらに、
「良いプログラマー」もしくは「隣に居るペアプログラマー」に、
具体的に以下のようなセンスを求めているということです。
# 「よいテスター」と書くから混乱させてしまったかもしれませんが、
プログラマがテストファースト時にテスターの帽子を
被って仕様を決めていく際には、鼻を利かせて「i == 0の時に
どうするか」に思いをめぐらせないといけない。
結果的に、
呼び出し側の債務にして事前条件として書くのでもいいし、
Exceptionが返る仕様にしてテストを書くのでもいいし、
double / intのときでもInfinityが返る仕様にしてテストを書くのでもいい。
できればカバレジツール、コード品質検査ツールなどのツールが
助けてくれるといいんですが、サポートしてくれないので、
従来どおり人に頼るしかない、と。