おおむらです。
太田さん、こんにちは。
"Kenichiro Oota" <oota@....jp> wrote:
from "[XP-jp:00954] Re: テストのためだけのメソッド"
> これらの方法はBinderの「Testing Object-Oriented Systems」によるとそ
この本、持っているのですが、重いのでなかなか読めません :-)
本は歩きながら読むことが多いので、本のサイズが立方体に近くなると
重力の影響によって読書ができなくなります...ううむ。
この際、まじめに取組むかなあ＞自分
> 最後に、話はそれますが、XPのクラスを書く前にそれをテストするコードを
>書くというの言うのは非常に良いことだと思いますが、メリットデメリットを
>持っていると思います。
>
> メリットしては、
>
>・実装によらない要求を正しく反映したテストが書ける
>・テストを書くことによって要求が明確になっているかが分かる
二番目の項目と同じことを言換えているだけのようにも聞えますけど、
テストを先に書くことで、開発者は、自分が要求をどう理解しているか、
が分るだけでなく、自分の理解度にまっすぐに向合うことで、それを
明確にしようという客観的な態度が生れるような気がします。
また、要求の方向よりも、設計の方向に関して、自分の作ろうとしている
インターフェイスのおかしな点がコードを作る前に分るというのもある
ように思います。
心理学なのかな。
XPでは、単にテストを先に書くというだけでなく、それで開発を誘導して
いくところがあると思うのですが、そこらへんの開発者の心構えみたい
なものも込めて、XPのやり方は合理的な気がします。
> デメリットしては
>
>・正しくテストと作ったとしても、実装したクラスに対してすべての網羅が出
>来るとは限らない
網羅なんてことは頭っからあきらめているんですよね。XPの場合。
すこしはなしがずれますが、
XPでは、テストが、ある意味、「実行可能な仕様書」になってますよね。
まあ、テストなので本質的に不完全だから「仕様書」にはなりえないわけですけど、
あるクラスの使い方を知りたかったら、そのテストコードを読めば分るという
ような点で、仕様書のようなものと思います。
その点からは、クラスのprivateにタッチしないテストがいいのかな。
> というのがあります。どちらにしてもテストコードのメンテナンスの手間は
>残ります。
それ、思いますね。仕様が大幅にかわったらテスト全面的に書直すんだなあとか...
でも、仕様が変ったときなどにテストコードを書きかえるのは、しなくてはならない
仕事だし、そこからはじめるのは絶対正しい道のような気がするので、
ここはバカボンのパパとなって「それでいいのだ」と思います。