<200111120549.AA00141@....jp> の、
"[XP-jp:02784] Re: XP セミナーレポート" において、
"SUZUKI Toru <tsuzuki@....jp>"さんは書きました：
ひがです。
> 鈴木＠名古屋です。
>
> Momijiya@....com さんは書きました。
>
> >私が考え過ぎなのかもしれませんが、DB更新の場合はまっさらのデータでテスト
> >したほうがいいのかなと言う点でした。
> >データが更新された事の確認は簡単なのですが、更新されていない事の確認は
> >どうするのだろうと。
> >例えば、とんでもない部分が過って更新されている場合、全データを検証しない
> >と問題が見つからないような気がして。
> >ユニットテストの範疇ではないのかもしれませんが。
>
> たしかにユニットテストの範囲を超えてしまいますね。うちの場合はDB への
> アクセス方法を統一するために、JDBCのラッパークラス（いわゆる Facade パターン）
> を作成し、皆そこを介してSQL文を発行しています。ある処理で、発行している、
> SQL文はそのラッパークラスが受け取った SQL 文を見れば分かるし、UPDATE 文が
> 予期しないレコードを更新しているかどうかは、UPDATE文の戻り値を確認する
> ことで分かるようにしています。
>
うちのフレームワークでは、
スプーフィング(だます、なりすます)を
使っています。TestCaseでは、データをXMLで用意し、
自作のSpoofingDataSourceManagerクラスでデータをロードします。
javax.sql.DataSourceにアクセスするクラスは、
XMLがロードされていれば、SpoofingDataSourceManager経由
で、データ(XML)にアクセスし、XMLがロードされていなければ、
DataSourceにアクセスするようになってます。
データにアクセスするクライアントは、スプーフィングが
行われていることに気づきません。
> ただ、これはあくまで DB にアクセスする直前で網を張っているだけなので、
> たとえば、DB 内部で更新時トリガーを設定している場合、どこのデータが更新
> されるかは、分からないことになります。
>
トリガもJavaで自前で実装しているので、
DBがなくてもテストができます。
---
Yasuo Higa <higa@....jp>
INFORMATION SERVICES INTERNATIONAL-DENTSU,LTD.