こんばんは。和田です。
On Mon, 17 Nov 2003 20:18:09 +0900
shima tetuo <mlmlml@....jp> wrote:
> tetuoです。
>
> 先日このメーリングリストでも少し話がありましたが、mock objectを利用して
> のUnitテストについて少し皆さんの意見を聞きたい事があります。
>
<snip />
>
> ここまででの疑問点：
> mock objectを使用する事により、この記事で言うと実データを操作することな
> く、メソッドの挙動の正確さを確認しているだけだと思いますが、実際に実行さ
> れるべき"SQL自体"の整合性はどのようにテストすべきなのでしょうか？
> 例：本当にエラーの発生しないSQLかどうかの確認等
> 簡単に言えば、mock objectを使用する事によって確認していない"結果"は、ど
> こで確認すべきなのかと言う事です。
>
SQL自体のテストはMock Objectでテストできることの範囲を超えていると
思います。実際にデータベースに接続してみないと分からないことがたくさん
あって、その中の一つにSQLの挙動があるのだと思います。
[XP-jp:04711][XP-jp:04714]で石井さんが仰っているように、同じ結果になる
ようなSQLは何通りも書けますし、文字列としてSQLをテストしようとすると
「実装の詳細をテストするっていうアンチパターン」になってしまうのでは
ないでしょうか。
agileDatabasesのメーリングリスト
[http://groups.yahoo.com/group/agileDatabases/]
で同様の話題が出たときにも、受け入れテストや結合テストのような形で
SQLのテストをするという意見が出ていました。
詳細までは分かりませんが、その議論の中でFIT[http://fit.c2.com/]と
Fitnesse[http://www.fitnesse.org/]を使用して受け入れテストのような形で
SQLのテストをするということを言っていた人がいました。
「このようなパラメータを与えたらこういうような結果行が返ってくること」
などというような受け入れテストを書いてからSQLを書くことによって
テストファーストでプログラムとSQL文の開発(?)を行うことができるのでは
ないでしょうか。さらに受け入れテストを自動化しておくことによって、
デグレードを恐れることなくリファクタリングをしたり、SQL文を書き換えたり、
SQL文のパフォーマンスを上げたりすることなどが可能になると思います。
以上参考になれば幸いです。
--
Takuto Wada <t-wada@....jp>