S2JDBC-Genで作成したテストケースの実行

S2JDBC-GenでEntity・Service・Testパッケージ以下にクラスが自動生成されたので、テストケースをゴリゴリ書いてみようと思います。

本家サイト、Googleでの検索結果などを見ますと、自動生成時にあるクラスはテスト用のクラスで、何も考えずに実行して、うまくいくと、Serviceクラスとの連携ができているので、成功する、とのこと。

では、早速、実行です。

あっ、思い出しました。S2JDBC-Genを色々と調べていた時、「app.dicon」が参照しています「convertion.dicon」の＜arg＞タグの所をブランクにしていました（デフォルト=S2JDBC-Gen実行後は、定義されています）。。。
ここを元通りにすると、成功です。余計な事はしてはいけない、という事ですね。失礼しました。。。

Googleでの検索結果をみますと、

1.app.diconがない
2.private OrderVoucherService orderVoucherService;がない=Serviceの宣言がない

という事ですが、S2JDBC-Genがここはカバーしてくれていますので、S2JDBC-Genを使用しましょう！！！ですね。

では、次に普通にCRUDを試してみます。

いきなり、insert()と書くと、怒られました。。。
これは、自動生成されたクラスの親クラス　S2AbstractServiceを継承しており、既に定義されている、という事です。

S2AbstractService　→　AbstractService　→　OrderVoucherService

このような関係になり、OrderVoucherServiceの部分をゴリゴリ書いていきます。このあたりの詳細については去年のSeasar2のカンファレンスのプレゼン資料にあります。

このような感じのコードです。

public void testInsert() throws Exception {
OrderVoucher entity = new OrderVoucher();
entity.accountId = "11";
entity.accountName = "222";

int expected = orderVoucherService.insert(entity);
assertEquals(expected, 1);
}

サクッと、うまくいきました。ちなみに戻り値は成功した件数です。

さらに、

public void testInsertTx() throws Exception {
OrderVoucher entity = new OrderVoucher();
entity.accountId = "11";
entity.accountName = "222";

int expected = orderVoucherService.insert(entity);
assertEquals(expected, 1);
}

メソッドの後ろにTxをつけると、実行後ロールバックをしてくれるので、データベースにデータが書き込まれないです。これは非常に便利です。
一度実行し、成功したら、メソッドにTxをつける、というルールで開発すればいいです。

ちなみに、IDは自動的に発行しているので、Txで何回か実行した後、Txを外すと、データベースに格納される値がシーケンスの順番通りにはならないので。

Insertができるので、当然UpdateもDeleteも同じです。

//public void testUpdate() throws Exception {
public void testUpdateTx() throws Exception {
OrderVoucher entity = new OrderVoucher();
entity.id = Long.parseLong("6");
entity.accountName = "8888";

int expected = orderVoucherService.update(entity);
assertEquals(expected, 1);
}

//public void testDelete() throws Exception {
public void testDeleteTx() throws Exception {
OrderVoucher entity = new OrderVoucher();
entity.id = Long.parseLong("6");

int expected = orderVoucherService.delete(entity);
assertEquals(expected, 1);
}

問題なく、大丈夫です。
ちなみに、Updateですが、accountIdには何も設定しないで実行すると、実行後はNullになります。つまり、Update実行時の対象のEntityにはaccountIdは何も設定していなく、そのまま対象のEntityを更新するので、ここは注意が必要ですね（あら？とならないように）。
本家サイトを見ると、Nullを除外したり、対象の項目のみを設定したりなど、便利なメソッドが用意されているので、あとで、これを使用します。

他に、S2AbstractServiceが用意してくれたプレゼントとしては以下のメソッドがあります。

public void testCount() throws Exception {
long expected = orderVoucherService.getCount();
assertEquals(expected, 1);
}

public void testDefaultFindAll() throws Exception {
List lists = orderVoucherService.findAll();
assertEquals(lists.size(), 1);
}

他にもありますが、私が勝手に使用する可能性があるメソッドのみピックアップしています。

サービスクラスに何も書かずに、ここまでテストケースが完了しました。おそるべし、という感じです。S2AbstractServiceを継承するという事が推奨されている、という事も納得です。

では、次にサービスクラスに記述するテストを書いていきます。

遅ればせながら、フィールドに「_」がある項目も問題なく実行できる事を確認しました。