お世話になっております。
藤田と申します。
> i) SQLが正しいか。
SQL自体の正当性を検証するのはかなり難しいとおもいます。
（というか今まさに参加しているプロジェクトで、技術統括をしてるえらい人か
ら指摘されました）
そのえらい人いわく、超レガシー（ネットワークDBとかVSAMファイル）からシス
テム移行でRDB化する場合、SQL（特に複雑なWHERE句）を正しく書けているかを
検証しきれなくて、はまるという事例が割と多く発生しているとのことです。
確かにSQLUNITみたいなものがあればよいのでしょうが、何か、有効な解がな
いか考えどころです・・・・。
----------------------- Original Message -----------------------
On Tue, 18 Nov 2003 14:17:04 +0900
安井 <yasui@....jp> wrote:
> こんにちは、安井＠Aspacです。
>
> shima tetuo wrote:
> > 1.正しい追加SQLが発行されているか
> > 2.SQLへのパラメータとしてメールアドレスと名前が設定されているか
> > 3.Executeが1回だけ実行されているか
> > 4.Closeが1回だけ実行されているか
>
> わたしだったら、テストを以下のように分割します。
>
> i) SQLが正しいか。
> ii) 正しいパラメータが渡されているか。
> Executeが1回だけ実行されているか。
> Closeが1回だけ実行されているか。
>
> そのうえで、実際にSQLを発行するのは別クラスに分離して(DAO
> パターン？)、そちらでは実際にDBに書き込んだ内容を確認しま
> す。mock object で確認するのは ii) の箇所だけにします。
>
> ほかの皆さんはどんなふうにしますか？ほかのやりかたも知りた
> いので、ぜひ教えてください。
>
> > 簡単に言えば、mock objectを使用する事によって確認していない"結果"は、ど
> > こで確認すべきなのかと言う事です。
>
> SQLを実行した結果自体は、どうしてもDBを使ってテストしたい
> ですね。ご紹介の記事にあった、
>
> > Of course, we will also need integration tests to check
> > the whole process, but those should be more like an
> > acceptance test for a larger module.
> (意訳：もちろん処理全体のテストは必要になる。それはもっと大
> きな単位での受け入れテストとして扱ったほうがよい。)
>
> という部分は、たとえば「ユーザー登録してからメールを送信す
> ると新しいユーザにも届く」というテストで確認すればよい、と
> 言っているように思いました。でもそれっていきなり規模が大きく
> なりすぎて、バグを追跡するのが難しくなるなあ。
>
> --
> アジアパシフィックシステム総研 ソリューション３部 安井 力
> http://www.asia.co.jp/ yasui@....jp
> 03-3985-3886 / FAX:03-3985-3778
>
--
藤田 <phujita@....com>