以前のモックフレームワークの技術的制約 今まで私が担当してきたプロジェクトにおいては、モックオブジェクトを使ったJUnitの単体試験はjMockとEasyMockのいずれかのフレームワークを利用して行ってきました。しかし、これらのフレームワークはJavaプラットフォームにおけるコード自動生成の考え方の変遷で説明したように動的プロキシーに基づいているため、以下のような制約がありました。 モック化する対象の型はインターフェースを実装しているか、継承可能なクラスであること モック化するメソッドはfinal、static、privateでないこと*1 モック化するロジックはコンストラクターの呼び出しではないこと モックオブジェクトをテスト対象クラスにDIかパラメーター経由で引き渡すことが可能であること モック化する場合はクラス全体をモック化する必要があること（getterやsetterなどは本物の
S2UnitはDBを使ったユニットテストの支援機能としてExcelファイルからDBにテスト用データを投入したり、ExcelファイルとDBの内容を比較したりすることができます。ただ、実際にやってみるとわかるのですがこのExcelファイルのメンテナンスコストが馬鹿になりません。 そこで、実際にDBにアクセスするのではなく、フレームワークやJDBCドライバのレイヤで発行されたSQLを横取りし、期待通りのSQLが発行されたのかどうかを確認するという方法はどうだろう？と考えました。そういうライブラリを自作しようかとも思ったのですが（実際途中まで作っていたのですが）、世の中同じことを考える人はいるもので、MockRunnerのJDBC Mockという機能を使うとそのものズバリなことができるようです。 http://mockrunner.sourceforge.net/examplesjdbc.html
先日紹介したMockRunnerのJDBC Mockですが、実戦投入を前提にチームのメンバーに見てもらっているのですが、いろいろと機能があるようです。たとえば以下のような感じでSQLの期待値の比較方法を制御することができます。 // 大文字・小文字を無視 jdbcTestModule.setCaseSensitive(false); // 期待値のSQLに正規表現を利用可能にする jdbcTestModule.setUseRegularExpressions(true); 正規表現を使えるので、 jdbcTestModule.verifySQLStatementExecuted( "SELECT .* FROM TABLE WHERE ID=\\?"); なんて書いておくとテーブルのカラム追加・削除くらいではテストケースを直す必要がなくなります。便利ですね。欲を言えばSQLの改行や空白の差
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
