矢崎です。
omura@....jp さんwrote:
>
> とにかく、一番重要なのはテストをすることなので、reflectionを使うことに決めて
> しまって、それで面倒くさくなってテストをやめたりしたら、本末転倒ですから。
>
reflectionを使うかどうかに限らず、確かに、テストが面倒くさく
なるようだとテストをしなくなる可能性が高まります。そうなると、
XPの根幹を揺るがしかねませんね。
例えば、あるクラスについて、コンストラクタでデータを
与えてやるが、そのデータを取り出すためのgetメソッドが
いらないような場合を考えます。当然そのデータは必要が
あるからコンストラクタの引数で渡したわけだし、おそらく内部
で保管されていて、あるメソッドで使われることでしょう。しかし、
それをgetメソッドで取り出すニーズはない、ということです。
例として、コンストラクタでSQL文を与えて、
executeとメソッドで、DBからSQLでデータを取得するような
オブジェクト、SqlHandlerなるものを考えます。
SqlHandler aSqlHandler = new SqlHandler("SELECT XX,YY, FROM ZZ_TBL");
ResultSet rs = aSqlHandler.execute();
SqlHandlerはSQL文がないと意味がないので、これをコンストラ
クタで与えています。しかし、それを後から取り出す必要は
ない（とここでは考えているとします）。後必要なのは、
コンストラクタで与えられたSQL文どおりの結果をDBから
取り出し、クライアントに返すということです。したがって、
JUnitでテストする場合、コンストラクタとexecuteメソッド
のテストになります。
人情としてはコンストラクタの実行の後、正しくSQL文が
渡ったかどうかを確認したくなるところです。しかし、もし
テストのためだけのメソッドがだめ、となると、それを確認
するのはexecuteを実行して、その結果、つまり取得した
ResultSetの結果を判断して、渡したSQLどおりの抽出
結果になったかどうかを判断する、ということになります。
これはこれで正しいかもしれませんが、テストをさっと書い
て、さっと実行する、というリズムは狂うかもしれません。
この例では、まだ因果関係がわかりやすいのですが、もう
少し複雑になると、テストを書くこと自体に頭を非常につか
い、時間がかかり、テスト自体がまちがっていた、というこ
とにもなりかねません。
そう考えると、少なくともget系のメソッドは、テスト用でしか
ないとしても、作ってよい、くらいはしたほうがいいのかもし
れませんね。
#早くも自分の考えに自分で反論してしまいました。
>
> ◇
> それから、ここらへんの迷いは、JUnitでのテストでは、何をテストすればいいの？
> という疑問がきっちり解明されていないからかもしれません。white boxテストだといっても、
> クラスの内部構造にべったりのテストは、本当に望ましいのか？ とかいう疑問は
> あります。
JUnitはあくまでツール（Framework)なので、それをうまく使うか
どうかは人間次第というわけですね。JUnitを使って、どうテストして
いくか、何をテストしていくか、というのは、課題だと思いました。
何かお考えございましたら、教えていただけませんでしょうか？
--
矢崎 博英 <firo@....jp>