単体テストにおいてDAO*1周りは、世の中の風潮として、
「テストがすぐに終わらないからその部分はMockで代替」
とされてしまうことが多いと思います。
たしかに重要なのは永続化することではなく、永続化する為のデータを作る
ビジネスロジック部分であることは否めません。
ですが、
- 永続化がきちんとできているか
- 永続化されたものを取り出す
ことのテストも同じくらい重要な気がします。
例えばWebアプリケーションの場合、
画面に表示するデータがきちんと格納されていなければ
「おや？」とすぐ気づくことができますが、
直接画面に表示しない情報(ex.status)を保持/更新するとかの場合は、
気づきにくいと思われます。
トランザクションの問題かもしれませんし、そもそも永続化処理を呼んでいないかもしれない。
それを毎回Webブラウザの打鍵で確認するのは非常に効率が悪い。
「永続化処理が呼べているか」レベルの確認はMockを使えば確認できますが、
- 本当に永続化できているか
- 取得条件に合致するデータが永続化されたものから取得できているか
の確認は、実際のRDBMSに問い合わせてみないと確認できません。
それを実行が「重い、遅い」というだけの理由でばっさりと切り捨てて
しまうことははなはだ疑問が残るわけです。
Webブラウザからの打鍵で「おや？」と気づいてからの
問題の特定までの時間はできるだけ短いほうが良い。
個々の処理(メソッドの振る舞い)は想定通りであることを担保する為に
単体テストが重要なわけで、
RDBMS周りもきちんとテストしましょうぜ、というのが昔からの想い。
テスト専用のスキーマとCIツールを用意すれば
超大型案件とかでなければ*2そんなにレスポンスが気にならないと思うんだけどな。
複雑な結合条件のSELECT文なのに、
簡単にデータを用意してコマンドラインからSELECT文を実行して
「SELECTのテスト終わり」としちゃう人のなんと多いことか。
SQLも開発言語なんだから、想定した挙動であるかはきちんとテストしなきゃいかんと思うのです。
結合条件に全て合致する/1つでも合致しないものがある時に
レコードが取得できるかというテストが。
面倒であることは間違いないのですが、何か問題が発生したときの
対応コストがぜんぜん違うと思うんですよね。
パフォーマンスチューニングでSELECT文を書き換えた時に
「取得できるデータ自体は変わらない」ことを確認する為にも
有用だと思うんだけどな。
