JUnitとか単体テストというキーワードに必ず付いてくる言葉に
「モック」が付いてきますが。
恥ずかしながら、あまりその有用性が見出せてません。
外部システムとの連携の為に
むやみに通信してはいけない、ということで
スタブを作るのはわかります。
試験するたびに誰かの口座からお金が減るのは嫌ですし。
呼び出したこと、その引数が確認できれば
アプリケーションとしての責務は果たしているのですから。
ただ、DBアクセスする所（DAO）をモック化して
そのデータを扱って何かする箇所の試験をする
というのが解せません。
仮にモックを作ったとして、
DAOの仕様が変わったらそれも直すんですよね？
モックが返すデータパターンも
せっせとコーディングするんですよね？
とっととDAO作ってDBのデータをいろいろなパターンで入れた方が
効率的じゃないのでしょうか？
Excel+DBUnitとか使って。楽ですよ。
もちろん、DAOの設計がきちんと終わってからということになりますが
大体小さな共通部品とかDAO辺りから設計しませんか？
新規開発の時はそれでもいいんですけど、
二次開発の時なんかは初期メンバーが総とっかえなんてざらでしょう。
その時の挙動が正しいかというのは実際のDB見たケースの方が安心できると思うんです。
私ならモックが正しいことをまず確認してしまうかも。
ロジックの挙動が正しいことを保証する為のテストコードだと思うんですけど
モックが正しいことって誰が保証できるんでしょうか？
他のシステム開発って、時間がかけられるのかなぁ、と思ってみたり。
もう少し考えてから追記しようと思いますけど、これを見かけた方、意見下さいませ。
