こんにちは、安井＠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