DBUnitでのテスト戦略
今考えているもの。
メソッド一つにテストケース一つではなく、テストのロジックは一つで複数のテストケースに対応したい。
となると、テストケースはXMLでテストクラスはある命名規則に従ったXMLファイル群を読み込み、テストごとにそれをパラメータとして扱う形がいいだろう。
テストケースを複数用意し、イテレーションでテスト駆動メソッドに渡す。テストメソッドは渡されたテストケース一つを実行する。
そのときのパラメータは
■参照系
・DB初期化データ(xml定義)
・参照メソッドのパラメータ(xml定義)
・参照後の期待値データ(xml定義)
・期待値データと参照メソッドで取得したentityを比較
■更新系
・DB初期化データ(xml定義)
・更新メソッドのパラメータ(xml定義)
・更新後の期待値データ(xml定義)
・更新メソッド実行後に期待値とリアルDBのデータを比較
両方とも、テスト対象クラスの内部プロセスではなくDBのデータに注目するブラックボックステストとして考える。
ここで問題になりそうな点
・DBのソート順。DBUnit経由のデータは自分でソートしないといけないのでソートカラムがパラメータに必要
・無視するカラムの設定。自動更新のタイムスタンプカラムなどは期待値を定義するときに予期できないので、無視する必要がある。
・DELETE_INSERTでPK自動采番の場合、インデックスナンバーを0に初期化して、後は素直にassertEquals(dataset,dataset) でOK。
そうでない場合は、PKの最高値を動的取得して検索・更新メソッドのキーにする。
順番として、
１データ投入、PK取得。
２キーでデータ参照。
３キーと初期値パラメータでデータ更新。
４キーでデータ削除。
DBデータと期待値比較時は、既存DBデータ＋期待値 == 現在のDBのレコード群と比較。そんな面倒なことやってられるかっつーの。だいたいDBUnitフレームワークの戦略に一致しない。例えば、ビジネスロジックにレコード入力件数制限があるなら、MAX値の場合は削除して挿入しないといけない。そんなことを動的にプログラムするか？それは「たまたまその状態になったので、そーしたテストケースが走る」より、初めからその状態を予期したテストケースを挙げた方が遥かによい。
■テストケースになるもの
・正常系CRUD
・正常系CRUDでDB・パラメータの状態により分岐が発生するもの。
これは仕様が明確であるならコーダではなくSEがDB初期値データ・期待値データを静的に定義可能。分岐の数がテストケースの数になる。
・異常系CRUD 例外が起こることを確認
・DBのデータによりValidateするタイプ
isValid == false なデータを用意し、業務プロセスが完遂しないことをチェック
●参照系
・存在しないデータのキーで検索したら、検索結果が0なことを確認
・存在するデータのキーで検索したら、検索結果が期待値と同一であることを確認
●挿入
・データ投入したら、期待値がDBに存在することを確認
●更新
・データ更新したら、DBのデータが期待値で更新されていることを確認。このとき、対象レコード以外がWhere句にマッチして予想外のデータが書き換わっていないか確認しないといけないので全レコードを期待値と比較
●削除
・存在しないデータのキーで削除したら、削除に失敗することを確認
・存在するデータのキーで削除したら、DBにデータが存在しないことを確認
このとき、対象レコード以外がWhere句にマッチして予想外のデータが削除されていないか確認しないといけないので全レコードを期待値と比較
