  |
うーん、そこは JUnit の使い方でなんとでもなる。
１つのテストケース動かす度にテーブル作り直すとかありえないし。
テーブルは作り直さずとも、テーブルの中身を truncate でひっくり返して、事前データをブチ込み直すくらいならば平気。
某銀行系での例。マジ怒られそうだから、若干ボカして書くけど、
ひとつのテストメソッド TestXxxDAO.testRetrieveFooBar() は、XxxDAO.retrieveFooBar() メソッドについての複数のパターンのテストを全てやる事にする。そのテストメソッドの中で
というサイクルを繰り返す。テストデータや想定結果は、全て OpenOffice calc なんかを使って、視覚的に書いておく。その ods ファイルを読み、DB に突っ込み、想定結果と比較する処理は独自フレームワークとして用意。ods ファイルは、「こういうデータを準備して、こういう引数でメソッドを呼ぶと、こういう結果になりました」というテストのエビデンスにもなる。
insert 後に select とかってのが切り離して考えられない処理ならば、それはそういう 1 単位の挙動だ。俺なら例えば、XxxDAO.insertFoo()、XxxDAO.retrieveBar() を作ってテストした上で、そいつらを XxxLogic.doSomething() に押し込むね。そしてやはり上記のようなテストが出来る。
頭の中だけだと「それって現実的じゃなくね？」と思えるかも知れないけど、実際やってみるといい。テスト順なんか気にせずにやっつけてしまえるし、案外これで効率よく厳密なテストが出来る。それでもヘタクソな野郎は、テスト順に依存したテストを作りやがって、後でメンテする俺涙目みたいな事にもなるけど。
これでテストデータを作るのが死にそうなほど大変であれば、メソッドの粒度を見直すべきかも知れない、というセンサーにもなる。・・もっとも、XxxLogic.doSomething() などを処理順に纏めた XxxAction.action() なんかのテストともなれば、やっぱ大変なんだけども。
副作用のあるテストを書かせないためかもしれないけど。 でも、テストって普通、簡単なものから難しいものへ、順番に書いてくんじゃないの？ そうなってないと品質上げていきにく...
うーん、そこは JUnit の使い方でなんとでもなる。 １つのテストケース動かす度にテーブル作り直すとかありえないし。 テーブルは作り直さずとも、テーブルの中身を truncate でひっ...
TestNG使いましょう。
5
