ハンズオンセクション 2

概要

さて、ハンズオンの続きです。

"データ登録をしてConditionBeanで基本の検索" をしていきましょう。

事前準備

org.docksidestage.handson.exercise.HandsOn02Test クラスを src/test/java (Testクラス置き場) に作成してください。 このクラスは UnitContainerTestCase を継承します。また、ERDを開いておくと良いでしょう。

マスタデータの登録

ここでいうマスタデータとは、会員ステータスなどの固定的なテーブルを指します。(開発環境でも、本番でも変化しないようなテーブル、例えば区分値など)

マスタデータがないことを確認

localdb/login-mysql-root.bat|sh で MySQL にログインして、会員ステータスが一件も存在しないことを確認してください。

e.g. 会員ステータスの件数を取得 @SQL
-- MaihamaDBに接続
use maihamadb;

-- 会員ステータスのカウント検索
select count(*) from MEMBER_STATUS;

マスタデータを配置して再びReplaceSchema

tutorial/material/dbflute/playsql-loaddata-common.zip (commonの方です) を解凍して、10-master.xls を、以下のように配置して、ReplaceSchemaを実行してください。

e.g. マスタデータ用のエクセルファイルの配置場所 @Directory
PROJECT_ROOT
 |-...
 |-dbflute_maihamadb
 |  |-dfprop
 |  |-...
 |  |-playsql
 |  |  |-data
 |  |  |  |-common
 |  |  |     |-xls
 |  |  |        |-10-master.xls
 |  |  |-replace-schema-00-system.sql
 |  |  |-replace-schema-10-basic.sql
 ...

マスタデータが入ったことを確認

先ほどの会員ステータスのカウント検索の結果が 0 でないことを確認してください。

テストメソッドの作成

こんどは、テストデータの登録ですが、先にテストメソッドを書いて、テストデータが入っていることをアサートしてみましょう。 まだデータを登録する前ですから、テストは落ちるはずです。

テストデータがあることをアサートするテスト

HandsOn02Test に、会員(MEMBER)のデータをアサートするテストを書いて "落ちること" を確認してください。テストメソッド名は test_existsTestData() とします。

このプロジェクトでは、メソッド名が test で始まることで、それがテストメソッドであると認識されます。 今後、テストを作成する際は、必ず "test何々" という形式でメソッドを作成してください。

テストメソッドの雛形

_test と打って ctrl + space して enter するとテストメソッドの雛形が作成されます。

e.g. テストメソッドのコード補完 @Java

public class HandsOn02Test extends UnitContainerTestCase {

    _test // _test と入力して ctrl + space して enter
}
--

public class HandsOn02Test extends UnitContainerTestCase {

    public void testname() throws Exception { // name の部分が入力モードに
        // ## Arrange ##

        // ## Act ##

        // ## Assert ##
    }
}

テストコードのお約束コメントの Arrange や Act のコメントが付与されているかと思います。 実はこれは、セクション1で DBFlute のエディターテンプレートを設定したからです。

メソッド名とBehaviorの宣言

テストメソッド名は、"test_existsTestData()" とし、MemberBhv を private のインスタンス変数として宣言してください。 Lasta Di では、@Resource というアノテーションを付けるとDI対象フィールドとなります。(_lap という補完を使うと少し楽になるかも)

e.g. test_existsTestData() の実装準備 @Java
public class HandsOn02Test extends UnitContainerTestCase {

    @Resource
    private MemberBhv memberBhv;

    public void test_existsTestData() throws Exception {
        // ## Arrange ##

        // ## Act ##

        // ## Assert ##
    }
}

テストコードの実装

そして、絞込み条件なしのシンプルな検索処理を実装してみましょう。(いわゆる全件検索です)

Behavior の selectCount() を使って select count(*) を実行し、assertTrue()メソッドを使ってアサートしてみましょう。 (assertTrue() は、"assT" とまで打って ctrl + space すれば補完できます)

テストコードの実行

その UnitTest (test_existsTestData()) を実行して、落ちることを確認してください。 テストコードが正しく実装されていれば、テストデータはまだ入っていないので例外が発生し、JUnitのバー表示が赤くなる (redになる) はずです。

UnitTest は red から

ちなみに UnitTest は、最初 red になる状態で作っておいて、正しく修正した後に green になるようにしておくと良いです。 事前に何も実行せずに正しく修正してから green になっても、その UnitTest のプログラム自体がちゃんと正しいチェックをしているのかわからないからです。 (もしかしたら、別に正しい修正をする前から green になっちゃってたのかも...)

もし、Eclipse なら

テストを実行する際は、そのテストメソッドの中にカーソルがある状態で ctrl + 0 を押すと、そのテストが実行されます。これは Quick JUnit のショートカットです。

テストデータの登録

テストデータを配置して再びReplaceSchema

tutorial/material/dbflute/playsql-loaddata-ut.zip (さっきと違ってこんどは ut の方です) を解凍して、20-member.xls30-product.xls を、以下のように配置してください。

e.g. テストデータ用のエクセルファイルの配置場所 @Directory
PROJECT_ROOT
 |-...
 |-dbflute_maihamadb
 |  |-dfprop
 |  |-...
 |  |-playsql
 |  |  |-data
 |  |  |  |-common
 |  |  |  |  |-xls
 |  |  |  |     |-10-master.xls
 |  |  |  |-ut
 |  |  |     |-xls
 |  |  |        |-20-member.xls
 |  |  |        |-30-product.xls
 |  |  |-replace-schema-00-system.sql
 |  |  |-replace-schema-10-basic.sql
 ...

再び ReplaceSchema を実行

さあ、実行してみてください。

ログを読んでみましょう

落ちるはずです。ログを追って、何が起きたのか? を把握してみましょう。 コンソールが見づらければ、DBFluteクライアント(dbflute_maihamadb)の log/dbflute.log を見るとよいでしょう。

ログを読むものハンズオンです。DBFluteタスクが必ず成功するとは限りません。 設定にミスがあれば遠慮なく落ちますので、落ちたときの分析方法をしっかりと知っておきましょう。

ちなみに、問題分析と問題解決をごちゃまぜにしないようにしましょう。 まずは分析が大切です。分析の前に解決方法のことばかりを考えてると、解決のヒントを見逃してしまいがちで本末転倒です。

defaultValueMap.dataprop

原因わかりましたでしょうか?...どういう風に解決していきましょうか。

20-member.xls を開いてみてみてください。NotNull制約のついている共通カラムのデータがありません。 ここでは、(DB上ではなく)ReplaceSchemaにデフォルト値を設定して解決しましょう。 同じディレクトリに以下の内容で defaultValueMap.dataprop というファイルを作成して、ReplaceSchemaを再実行してみましょう。

e.g. 共通カラムのデフォルトテストデータの設定 @defaultValueMap.dataprop
map:{
    ; REGISTER_DATETIME = sysdate
    ; REGISTER_USER     = foo
    ; UPDATE_DATETIME   = sysdate
    ; UPDATE_USER       = foo
    ; VERSION_NO        = 0
}

テストが通ることを確認

再度テストを実行し、テストが通ってJUnitのバー表示が green になることを確認してください。

テストデータの閲覧

さて、ここでじっくり ConditionBean について学んでみましょう。

せっかくなので、どのようなデータが入っているかさらに見てみましょう。 以下のテストを作成してください。(メソッド名の先頭にtestを付けましょう。メソッド名はいい感じに...)

会員名称がSで始まる会員を検索 (これはタイトル、この中にも要件が含まれている)
  • 会員名称の昇順で並べる (これは実装要件、Arrange でこの通りに実装すること)
  • (検索結果の)会員名称がSで始まっていることをアサート (これはアサート要件、Assert でこの通りに実装すること)
会員IDが1の会員を検索
  • 一件検索として検索すること
  • 会員IDが 1 であることをアサート
生年月日がない会員を検索
  • 更新日時の降順で並べる
  • 生年月日がないことをアサート

アサートだけでなく、テストコード自体が想定通りか?を確認する意味でのログの出力も実装すると良いでしょう。 テストコード内では、log()メソッド が利用できます。 ログに何を出力するかは自由です。ただ、ログも綺麗に 出しましょう。

本来、UnitTestというのは、mainコード (src/main/java) を、testコード (src/test/java) で呼び出して、検証をするというものですが、セクション5までは、シンプルな形で DBFlute を体験してもらうために、Arrange と Act が main コード と想定して、Assert をしていきます。

コード補完を駆使して実装

DBFluteは、Java (コンパイル言語) の良さを最大限活かしていくことに重きを置いています。

ぜひ、ショートカットとコード補完を駆使して、気持ちよく実装していきましょう。 最初は全然ゆっくりでOKです。ハンズオンでじっくり手に馴染ませて、本番(業務の実装)でスピーディーに実装できればいいわけなのです。

ConditionBeanの機能を探したいときはどうする?

ぜひ、"ディベロッパーのFAQ" をじっくりお読みください。

ディベロッパーのためのチュートリアル - ディベロッパーのFAQ

まずは、DBFluteに関係なく やりたいことを明確にすること これを重要視しています。 それさえハッキリすれば、その一つ一つの "目的" から、おのずと機能が探しやすくなっているはずです。

(ConditionBeanを覚えるためにやっているというのに...) いきなりConditionBeanのことを考えるのではなく、要件をよく読み、ERDのテーブル構造と照らし合わせて検索イメージを湧かせることが大切です。

すでに何十人の人にハンズオンを行っていますが、(もちろん経験の差もありますが) 自力で機能を見つけられる方と苦戦される方の大きな違いは、そこにあると感じています。 見つけ方、それがわかってしまえば、機能を丸暗記する必要はないのです。

これは DBFlute に限らない話で、覚えることのあまりに多過ぎるこの世界でやっていくための、とても重要なスキルと言えると考えていますので、ぜひここで意識してみてください

模範解答的な

模範解答的な実装を紹介しています。(参考までに)

次のセクション

さて、次のセクションへ