JUnit入門その7[Eclipse4.4のJUnitプラグインとDBUnitの併用(更新系のテストの実装)]
JUnit入門その6[Eclipse4.4のJUnitプラグインとDBUnitの併用(便利に利用するためのユーティリティの作成)]
ではDBUnitを便利に利用するためのユーティリティ(と言っても基底クラスでが・・・)の説明をさせていただきました。
今回は、更新系のテストの実装方法の説明をさせていただきたいと思います。
本エントリーの内容は以下の通りです。
- 更新系テストの実装方法の説明
- 更新系テストの実装例とその説明
- 期待値データとデータベースの比較方法
1 更新系テストの実装方法の説明
更新系テストにおけるポイント
更新系のテストと一括りで書いてますが、実際には、新規作成(Insert)、更新(Update)、削除(Delete)が含まれています。
各更新系のテストでは、DBアクセスロジックが正しく実装されている事を担保するだけではなく、DBのメタデータ(主キー、カラムの属性や、カラムの長さ等)がDB設計通りになっているかを確認する必要があります。
上記の内容は、DBUnitを利用しなくてもテストを実装可能ですが、テスト実行後のDBデータの検証はDBUnitを利用しないと難しいといえます。ここがDBUnitの真価を発揮する所です。
新規作成のテストの実装時のポイント
テスト対象となる。DBアクセスロジックの操作対象テーブルの各カラムに対するテストケースのポイントは以下のの通りです。
- nullが許可されているカラムにnullが登録できること。
- not null制約のカラムにnullが登録できないこと。
- カラム長が存在する場合、最大長のデータが登録できること。
- カラム長が存在する場合、最大長より長いデータが登録できないこと。
- 一意制約のカラムは、それに違反するデータが登録できないこと。
- 参照整合性制約が設けられたカラムには、それに違反するデータが登録できないこと。
当然ですが、DBアクセスロジックのホワイトボックステスト的な観点でのテストケースは必須です。
あと、これは私の好みの問題かもしれませんが、新規作成でかつ、新規レコードが作成されないパターンのテストでも、テスト実行後のDBデータの検証処理は実装しておくべきだと考えます。前提値データをそのまま期待値データに指定すればOKですのでテストデータが増える事もないです。
とは言え、例外が発生することを@Testアノテーションのexpectedを利用して検証する場合はその方がスマートだとも言えます。
もう1点、気になるポイントとして、複数テーブルにレコードを作成する時のエラー処理ですね
テーブルA、テーブルB、テーブルCとの順番で1レコードずつ新規作成する処理の場合は、テーブルCにレコードを作成失敗時のロールバック処理が正しく実装されている事のテストケースは必須だと言えます。エラー処理を言い出すときりがないですが・・・
更新のテストの実装時ののポイント
テスト対象となる。DBアクセスロジックの操作対象テーブルの各カラムに対するテストケースのポイントは、新規作成の時と同様です。
DBアクセスロジックのホワイトボックステスト的な観点でのテストで注意するポイントとしては
- 更新対象のレコードが1件存在する場合
- 更新対象のレコードが複数件存在する場合
- 更新対象のレコードが存在しない場合
- 他のトランザクションの排他処理により更新処理が失敗する場合
他のトランザクションによる排他に関しては、リトライ処理を組み込んでいる場合は、リトライで更新がうまくいくテストパターンも必要となります。
繰り返しになりますが、それ以外のポイントはDB定義の検証のテストケースとなります。
削除のテストの実装のポイント
更新のテストのポイントと同様となります。
2 更新系テストの実装例とその説明
ユニットテストに利用するデータベースは「HyperSQL」となります。
環境作成に関しましては、
「HyperSQL」の環境を作成し、Eclipseの「DBViewer」プラグインを利用してSQLを発行してみる
を参照ください。
テストに利用するテーブルの説明
以下のようなテーブル：USERTBLを利用します。
|
1 2 3 4 5 6 |
CREATE TABLE USERTBL ( NAME VARCHAR(20) PRIMARY KEY, ADDR VARCHAR(40) NOT NULL, AGE INT ); |
「HyperSQL」の管理ツールやEclipseの「DBViewer」プラグインでデータベースに接続し、SQLを発行してください。
テスト対象のDAO
テスト対象のDAOは以下の通りです。
JDBCConnectionUtilにつきましては、
JUnit入門その6[Eclipse4.4のJUnitプラグインとDBUnitの併用(便利に利用するためのユーティリティの作成)]
をご覧下さい。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 |
import java.sql.Connection; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.sql.Statement; import jdbc.util.JDBCConnectionUtil; public class UserDAO { public boolean updateByName(String oldName, UserDto updateDto) throws Exception { Connection jdbcConnection = null; PreparedStatement pstmt = null; try { jdbcConnection = JDBCConnectionUtil.getJdbcConnection(); String sql = "update usertbl set name = ?,addr =? where usertbl.name = ? "; pstmt = jdbcConnection.prepareStatement(sql); pstmt.setString(1, updateDto.getName()); pstmt.setString(2, updateDto.getAddr()); pstmt.setString(3, oldName); int updateResult = pstmt.executeUpdate(); if (updateResult != 1) { return false; } }finally { if (pstmt != null) { try { pstmt.close(); }catch(Exception e) { } } if (jdbcConnection != null) { try { jdbcConnection.close(); }catch(Exception e) { } } } return true; } public boolean removeByName(String name) throws Exception { Connection jdbcConnection = null; PreparedStatement pstmt = null; try { jdbcConnection = JDBCConnectionUtil.getJdbcConnection(); String sql = "delete from usertbl where name = ?"; pstmt = jdbcConnection.prepareStatement(sql); pstmt.setString(1, name); int updateResult = pstmt.executeUpdate(); if (updateResult != 1) { return false; } }finally { if (pstmt != null) { try { pstmt.close(); }catch(Exception e) { } } if (jdbcConnection != null) { try { jdbcConnection.close(); }catch(Exception e) { } } } return true; } public boolean createUser(UserDto newUserDto) throws Exception { Connection jdbcConnection = null; PreparedStatement pstmt = null; try { jdbcConnection = JDBCConnectionUtil.getJdbcConnection(); String sql = "insert into usertbl(name, addr, age) values(?, ?, ?)"; pstmt = jdbcConnection.prepareStatement(sql); pstmt.setString(1, newUserDto.getName()); pstmt.setString(2, newUserDto.getAddr()); pstmt.setInt(3, newUserDto.getAge()); int updateResult = pstmt.executeUpdate(); if (updateResult != 1) { return false; } }finally { if (pstmt != null) { try { pstmt.close(); }catch(Exception e) { } } if (jdbcConnection != null) { try { jdbcConnection.close(); }catch(Exception e) { } } } return true; } } |
何の変哲もない、面白味に欠けるコードですが、このUserDAOに対してテストを実装して行きます。
UserDto.javaは以下のようになります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
public class UserDto { private String name; private String addr; private int age; public int getAge() { return age; } public void setAge(int age) { this.age = age; } public String getName() { return name; } public void setName(String name) { this.name = name; } public String getAddr() { return addr; } public void setAddr(String addr) { this.addr = addr; } } |
更新系のテストクラスの生成
UserDAOをクリックした状態で、「新規Javaクラス作成」ボタンの右側をクリックします。
すると、以下の画像のリストが表示されますので、「JUnitテスト・ケース」をクリックします。
すると以下のような画面が表示されます。
クラス名にUserDAOTest、テスト元クラスにUserDAOが既にセットされています。
スーパークラスをdbunitutil.DatabaseTestCaseExに変更し「次へ」ボタンをクリックします。
dbunitutil.DatabaseTestCaseExにつきましては、
JUnit入門その6[Eclipse4.4のJUnitプラグインとDBUnitの併用(便利に利用するためのユーティリティの作成)]
をご覧ください。
次に表示される画面では、以下の画像の赤枠部分のチェックボックスをチェックし、「完了」ボタンをクリックしてください。
このチェックによって、テスト元クラスのチェックを入れたメソッドに対するテストのひな形が自動生成されます。
と言っても名前とアノテーションだけなんですが・・・
生成されたクラスは以下のようになりました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
import org.junit.Test; import dbunitutil.DatabaseTestCaseEx; public class UserDAOTest extends DatabaseTestCaseEx { @Test public void testUpdateByName() { fail("まだ実装されていません"); } @Test public void testRemoveByName() { fail("まだ実装されていません"); } @Test public void testCreateUser() { fail("まだ実装されていません"); } } |
更新系のテストの実装前の前準備
@TestDataをテストクラスに付与
DatabaseTestCaseExでは、クラス定義に@TestData(baseData=”./testdata/testdata.xls”)のようなアノテーションを付与することで、前提値データ(パス=./testdata/testdata.xls)がデータベースにセットアップされる機能を実装していたのでした。
./testdata/testdata.xlsは、Eclipseのパッケージ・エクスプローラーで見ると以下のような位置に存在します。
詳細は、JUnit入門その6[Eclipse4.4のJUnitプラグインとDBUnitの併用(便利に利用するためのユーティリティの作成)]をご覧ください。
それにしてもNullPointerExceptionが発生するのは良くないですね・・・
と言う事で、@TestData(baseData=”./testdata/testdata.xls”)をUserDAOTestに付与しました。
./testdata/testdata.xlsの内容は以下のようになります。
db.propertiesの内容を変更
前回までは「Java DB」を利用していましたので、「HyperSQL」につながるよう設定を変更する必要があります。
変更後のdb.propertiesは以下のようになりました。
|
1 2 3 4 |
jdbcDriver=org.hsqldb.jdbcDriver jdbcUrl=jdbc:hsqldb:hsql://localhost/ dbUser=SA dbPassword= |
HyperSQLのJDBCドライバーのjarをビルドパスに追加
HyperSQLのlib配下に存在するhsqldb.jarをビルドパスに追加する必要があります。
詳細は
Eclipse4.4(Java)におけるビルド・パス関係の設定方法[JRAおよびクラス・フォルダー/ライブラリー]
をご覧ください。
Apache POIのバージョンを3.2-FINALに変更
現在のDBUnit(2015年4月現在は2.4.9)と最新のApache POIは相性が悪いようです。
http://archive.apache.org/dist/poi/release/bin/poi-bin-3.2-FINAL-20081019.tar.gz
から3.2-FINALを取得し、POIのjarを差し替える必要があります。
なお、xlsファイルに文字列しか存在しない場合は最新のPOIでも問題なく動作します。
現在のDBUnit(2015年4月現在は2.4.9)を最新のApache POIで動作させると以下のような例外が発生します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
java.lang.NoSuchMethodError: org.apache.poi.hssf.usermodel.HSSFDateUtil.isCellDateFormatted(Lorg/apache/poi/hssf/usermodel/HSSFCell;) at org.dbunit.dataset.excel.XlsTable.getValue(XlsTable.java:153) at org.dbunit.operation.InsertOperation.getIgnoreMapping(InsertOperation.java:120) at org.dbunit.operation.AbstractBatchOperation.execute(AbstractBatchOperation.java:172) at org.dbunit.operation.CompositeOperation.execute(CompositeOperation.java:79) at org.dbunit.AbstractDatabaseTester.executeOperation(AbstractDatabaseTester.java:190) at org.dbunit.AbstractDatabaseTester.onSetup(AbstractDatabaseTester.java:103) at org.dbunit.DatabaseTestCase.setUp(DatabaseTestCase.java:156) at dbunitutil.DatabaseTestCaseEx.setUp(DatabaseTestCaseEx.java:42) at junit.framework.TestCase.runBare(TestCase.java:139) at junit.framework.TestResult$1.protect(TestResult.java:122) at junit.framework.TestResult.runProtected(TestResult.java:142) at junit.framework.TestResult.run(TestResult.java:125) at junit.framework.TestCase.run(TestCase.java:129) at junit.framework.TestSuite.runTest(TestSuite.java:255) at junit.framework.TestSuite.run(TestSuite.java:250) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) |
新規作成のテストの実装例
新規作成のテストを実装してみます。実際のメソッドはtestCreateUserとなります。
新規作成のテストの実装例
データベース定義のテスト
「1 更新系テストの実装方法の説明」の「新規作成のテストの実装時のポイント」に関するテストを実装します。
とは言っても全てのパターンを網羅すると長くなりますので、数パターンのだけ実装してみます。
・null、not nullの検証テスト
addrはnot null制約が付与されいますので、addrにnullをセットした時に例外が発生するとのテストを実装します。
実際には、testCreateUserをコピーして、testCreateUser_addrにnullがセットできない検証メソッドを作成し、@TestアノテーションのexpectedにSQLException.classを指定するとの方法としました。
|
1 2 3 4 5 6 7 8 9 10 |
@Test(expected=SQLException.class) public void testCreateUser_addrにnullがセットできない検証() throws Exception { UserDAO userDao = new UserDAO(); UserDto newUserDto = new UserDto(); newUserDto.setName("新しい行のname"); newUserDto.setAge(20); userDao.createUser(newUserDto); } |
テストを実行してみると、失敗します。
java.sql.SQLIntegrityConstraintViolationExceptionがスローされているのだから、expected=SQLException.classと記載しているので、成功のはずですが・・・
色々試行錯誤した結果、UserDAOTestがDatabaseTestCaseExを継承していることが問題の原因でした。
DatabaseTestCaseExはDatabaseTestCaseを経由してjunit.framework.TestCaseの継承クラスです。
JUnit4系では、テストクラスでもjunit.framework.TestCaseを継承しなくてOKとなっており、この継承関係を作ってしまうと@Test(expected=が正常に動作しないようです。
DatabaseTestCaseExの作りを考え直さないといけないですね・・・
とりあえず今回はtry catchで対応するように変更してみます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
@Test public void testCreateUser_addrにnullがセットできない検証() throws Exception { UserDAO userDao = new UserDAO(); UserDto newUserDto = new UserDto(); newUserDto.setName("新しい行のname"); newUserDto.setAge(20); try { userDao.createUser(newUserDto); fail(); }catch(SQLException e) { assertTrue(true); } } |
これでテストは成功しました。
実際には、主キーはnot null制約を含むので、nameカラムに対するテストも実装すべきですが、今回は省略させていただきます。
・最大長を超えるデータが登録できないテスト
次に、nameに21文字、addrに41文字セットした時のテストを実装します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
@Test public void testCreateUser_nameとaddrに最大長プラス1をセット() throws Exception { UserDAO userDao = new UserDAO(); UserDto newUserDto = new UserDto(); //nameに21文字 newUserDto.setName("1234567890123456これで21"); //addrに41文字 newUserDto.setAddr("123456789012345678901234567890123456これで41"); newUserDto.setAge(20); try { userDao.createUser(newUserDto); fail(); }catch(SQLException e) { assertTrue(true); } } |
うんうん、ちゃんとテストが成功しました。
このテストメソッドでは、nameとaddrを同時に検証していますので、どちらのカラムに対する例外でもテストは成功しますが、nameは21文字登録できて、addrだけ41文字登録できない場合でもテストは成功してしまいますので、本来は別々に検証すべきです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
@Test public void testCreateUser_nameとaddrに最大長プラス1をセット() throws Exception { UserDAO userDao = new UserDAO(); UserDto newUserDto = new UserDto(); // nameに21文字 newUserDto.setName("1234567890123456これで21"); // addrに40文字 newUserDto.setAddr("12345678901234567890123456789012345これで40"); newUserDto.setAge(20); try { userDao.createUser(newUserDto); fail("nameに21文字セットできてはNG"); } catch (SQLException e) { assertTrue(true); } // nameに20文字 newUserDto.setName("123456789012345これで20"); // addrに41文字 newUserDto.setAddr("123456789012345678901234567890123456これで41"); try { userDao.createUser(newUserDto); fail("addrに41文字セットできてはNG"); } catch (SQLException e) { assertTrue(true); } } |
DAO自体のテスト
createUserメソッドのテストとしては、引数にnullが渡された時と、普通に登録が成功する時(戻り値がtrue)、登録が失敗する時の3パターン(戻り値がfalse)が存在すると思います。
と思いましたが、例外がスローされるので登録が失敗するパターンは現実的に存在しませんね・・・
それ以外は「データベース定義のテスト」の範疇です。
厳密には、データベースの排他処理も考慮すべきですが、今回は省略させていただきます。
・引数にnullが渡された時のテスト
現在のcreateUserメソッドの引数にnullを渡して呼び出すとNullPointerExceptionが発生します。
とっても格好が悪いですね、せめて引数チェックを行って、nullの場合はIllegalArgumentExceptionをスローするよう変更しました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
public boolean createUser(UserDto newUserDto) throws Exception { if(newUserDto == null) { throw new IllegalArgumentException("newUserDto is null"); } Connection jdbcConnection = null; PreparedStatement pstmt = null; try { jdbcConnection = JDBCConnectionUtil.getJdbcConnection(); String sql = "insert into usertbl(name, addr, age) values(?, ?, ?)"; pstmt = jdbcConnection.prepareStatement(sql); pstmt.setString(1, newUserDto.getName()); pstmt.setString(2, newUserDto.getAddr()); pstmt.setInt(3, newUserDto.getAge()); int updateResult = pstmt.executeUpdate(); if (updateResult != 1) { return false; } }finally { if (pstmt != null) { try { pstmt.close(); }catch(Exception e) { } } if (jdbcConnection != null) { try { jdbcConnection.close(); }catch(Exception e) { } } } return true; } |
テストメソッドは以下の通りです。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
@Test public void testCreateUser_引数にnullを指定() throws Exception { UserDAO userDao = new UserDAO(); UserDto newUserDto = null; try { userDao.createUser(newUserDto); fail("引数にnullが指定されたのに例外発生しない"); } catch (IllegalArgumentException e) { assertTrue(true); } } |
テストも問題なく成功しました。
・普通に登録が成功する時のテスト
このテストメソッドは以下のようになりました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
@Test public void testCreateUser_作成が成功() throws Exception { UserDAO userDao = new UserDAO(); UserDto newUserDto = new UserDto(); // nameに20文字 newUserDto.setName("123456789012345これで20"); // addrに40文字 newUserDto.setAddr("12345678901234567890123456789012345これで40"); // ageにはintの最大値 newUserDto.setAge(Integer.MAX_VALUE); // 登録が成功するかテスト assertTrue(userDao.createUser(newUserDto)); // DBUnitのコネクション生成 IDatabaseConnection connection = new DatabaseConnection( JDBCConnectionUtil.getJdbcConnection()); // 期待値データを読み込み IDataSet explDataSet = new XlsDataSet(new FileInputStream(new File( "./testdata/expecteddata1.xls"))); // 実際のDBの値を取得 IDataSet actIDataSet = connection.createDataSet(); // 比較 Assertion.assertEquals(explDataSet, actIDataSet); } |
nameに20文字、addrに40文字、ageにInteger.MAX_VALUEを指定してUserDaoのcreateUserを呼び出しています。
呼び出しが成功した事を確認した後、期待値データ(./testdata/expecteddata1.xls)とデータベースの中身を比較しています。
./testdata/expecteddata1.xlsの中身は以下のようになります。データが長いのでほとんど見えてませんが・・・
期待値データとデータベースの比較方法につきましては後述させていただきます。
更新・削除のテストの実装例
更新・削除のテストの実装例の説明もと思ったのですが、新規作成のテストと考え方は同じですので省略させていただきます。
3 期待値データとデータベースの比較方法
期待値データとデータベースの比較方法の説明をさせていただきます。
前述の「新規作成のテストの実装例」で記載させていただいた比較は、期待値データに存在する全てのテーブルのデータと、データベースに存在するそのテーブルのデータを比較する実装例となります。
DBUnitにはこの比較以外に、テーブルを指定した比較、クエリーを指定した比較が存在します。
期待値データに存在する全てのテーブルの比較
「普通に登録が成功する時のテスト」がコード例となります。
実際にはorg.dbunit.AssertionクラスのassertEqualsメソッドを利用します。
|
1 |
public static void assertEquals(org.dbunit.dataset.ITable expectedTable, org.dbunit.dataset.ITable actualTable) throws org.dbunit.DatabaseUnitException; |
比較するテーブルの認識法則
期待値データにA_TABLE、B_TABLE、C_TABLEが存在した場合は、データベースのA_TABLE、B_TABLE、C_TABLEにそれぞれ登録されているデータと期待値データのA_TABLE、B_TABLE、C_TABLEに登録されているデータを比較し、一致すればAssertion.assertEqualsが成功します。
カラムは全てのカラムが比較対象となります。もしデータベースのA_TABLEに存在するカラムが、期待値データのA_TABLEで全て定義されていない場合は以下のような例外が発生します。
|
1 |
junit.framework.ComparisonFailure: column count (table=USERTBL, expectedColCount=2, actualColCount=3) expected:<[[age, name]]> but was:<[[ADDR, AGE, NAME]]> |
比較時のソート順
期待値のデータは、行データの定義順(xls内の順番通り)で、データーベースのデータのソート順は、ソート未指定時の順番となりますので、データが全く同じ場合でも、xlsの行の並びがソート未指定時の順番と異なる場合はAssertion.assertEqualsは失敗します。
前述の「新規作成のテストの実装例」のexpecteddata1.xlsの中身が以下の内容であった場合はテストは失敗します。
障害トレースの1行目は以下のようになります。
|
1 |
junit.framework.ComparisonFailure: value (table=USERTBL, row=0, col=addr) expected:<[東京都]> but was:<[12345678901234567890123456789012345これで40]> |
テーブルを指定した比較
org.dbunit.database.QueryDataSetを利用することで、比較したいテーブルを指定することが可能になります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
// DBUnitのコネクション生成 IDatabaseConnection connection = new DatabaseConnection( JDBCConnectionUtil.getJdbcConnection()); // 期待値データを読み込み IDataSet explDataSet = new XlsDataSet(new FileInputStream(new File( "./testdata/expecteddata1.xls"))); // 実際のDBの値を取得 // QueryDataSetを作成 QueryDataSet actQueryDataSet = new QueryDataSet(connection); //比較を行いたいテーブル名をaddTableで指定する。 actQueryDataSet.addTable("USERTBL"); // 比較 Assertion.assertEquals(explDataSet, actQueryDataSet); |
と言っても、期待値のxlsにaddTableしたテーブル以外のシートが存在する場合は、その時点でAssertion.assertEqualsは失敗しますので、現実的にはこの方法だけでは用途はございません。
期待値のxlsに含まれるaddTableしたシートだけを含んだIDataSetを作り出さないと使えないとの意味です。
この点については別エントリーで記載させていただこうと考えております。
クエリーを指定した比較
Assertion.assertEqualsByQueryを利用することで、より細かい設定での比較が可能となります。
API仕様としては以下の通りです。
|
1 |
public static void assertEqualsByQuery(org.dbunit.dataset.ITable expectedTable, org.dbunit.database.IDatabaseConnection connection, java.lang.String tableName, java.lang.String sqlQuery, java.lang.String[] ignoreCols) |
実際のサンプルコードは以下の通りです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// DBUnitのコネクション生成 IDatabaseConnection connection = new DatabaseConnection( JDBCConnectionUtil.getJdbcConnection()); // 期待値データを読み込み IDataSet explDataSet = new XlsDataSet(new FileInputStream(new File( "./testdata/expecteddata1.xls"))); // assertEqualsByQueryの引数として // tableName="USERTBL", // sqlQuery="SELECT * from USERTBL", "USERTBL" // ignoreCols=new String[0] // を指定して呼び出し Assertion.assertEqualsByQuery(explDataSet, connection, "SELECT * from USERTBL", "USERTBL", new String[0] ); |
JUnit入門その7[Eclipse4.4のJUnitプラグインとDBUnitの併用(更新系のテストの実装)]は以上です。
関連記事
-
-
Eclipse4.4(Java)におけるビルド・パス関係の設定方法[ビルド・パス上のソース・フォルダー]
Eclipse4.4(Java)におけるビルド関係のビルド・パス上のソース・フォルダーの利用方法を説
-
-
Eclipse(4.3,4.4)のJava言語のリファクタリング機能の使い方[リファクタリングの説明と「名前変更」と「移動」]
本エントリーでは、Eclipse(4.3,4.4)の「リファクタリング」機能の使い方を説明させていた
-
-
JUnit入門その１[Eclipse4.4のJUnitプラグインの基本的な使い方]
利用する環境の作成につきましては、「Eclipseの使い方(Windows環境のEclipse4.3
-
-
JDK8(java 8)の新機能のラムダ式の利用方法[その3：java8が用意している関数型インターフェース]
[その2：関数型インターフェースを例としたラムダ式] と説明させていただいておりますが、
-
-
Java超入門 with Eclipse[1：Eclipse環境の作成とEclipseの使い方の説明]
「JDT betaを利用してJDK8(java 8)対応のEclipse開発環境を作成する」では、最
-
-
Eclipseの「JSDT-jQuery」プラグインでJQuery(JavaScript)のコード補完が可能な環境を作成する
Eclipse for JavaEE Developer等のWeb開発系のEclipseがインストー
-
-
Java8のラムダ式とStream APIを利用してコーディング量の削減サンプル集
Java8になりラムダ式と「Stream API」が利用できるようになりました。 C#では一足早く
-
-
Eclipseのインストールと日本語化とJDK8(Java8)対応[Eclipse4.4とEclipse4.3]
インストールするEclipseのバージョンですが、とりあえず4.3をターゲットとしておき、 4.4
-
-
Mac(OS X)におけるJava8(jdk8)等のインストール、アップデート、アンインストール方法
Windowsとは異なりMac(OS X)ではJDKの管理(インストール、アンインストール)が難しい
-
-
Eclipse(4.3,4.4)の使い方[各画面エリアの名称とパースペクティブのビューのカスタマイズ]
本エントリーでは、Eclipse(Eclipse4.3,4.4)の各画面エリアの名称の説明と、ビュー
