読者です 読者をやめる 読者になる 読者になる

単体テストとモック

JUnitとか単体テストというキーワードに必ず付いてくる言葉に
「モック」が付いてきますが。

恥ずかしながら、あまりその有用性が見出せてません。

外部システムとの連携の為に
むやみに通信してはいけない、ということで
スタブを作るのはわかります。
試験するたびに誰かの口座からお金が減るのは嫌ですし。
呼び出したこと、その引数が確認できれば
アプリケーションとしての責務は果たしているのですから。


ただ、DBアクセスする所(DAO)をモック化して
そのデータを扱って何かする箇所の試験をする
というのが解せません。

仮にモックを作ったとして、
DAOの仕様が変わったらそれも直すんですよね?

モックが返すデータパターンも
せっせとコーディングするんですよね?

とっととDAO作ってDBのデータをいろいろなパターンで入れた方が
効率的じゃないのでしょうか?
Excel+DBUnitとか使って。楽ですよ。

もちろん、DAOの設計がきちんと終わってからということになりますが
大体小さな共通部品とかDAO辺りから設計しませんか?


新規開発の時はそれでもいいんですけど、
二次開発の時なんかは初期メンバーが総とっかえなんてざらでしょう。
その時の挙動が正しいかというのは実際のDB見たケースの方が安心できると思うんです。
私ならモックが正しいことをまず確認してしまうかも。


ロジックの挙動が正しいことを保証する為のテストコードだと思うんですけど
モックが正しいことって誰が保証できるんでしょうか?

他のシステム開発って、時間がかけられるのかなぁ、と思ってみたり。


もう少し考えてから追記しようと思いますけど、これを見かけた方、意見下さいませ。