Apache Wicketを使ってみる[5] -テスト編-

0. Wicketのテストサポート

WicketTester というヘルパークラスがcoreパッケージに含まれていて、Servletコンテナを介さずとも JUnit 4 でユニットテストを簡単に実行できるようになっている。

1. 簡単な使用例を実際に動かしてみる

前述の WicketTester の先頭にある使用例を Kotlin でかいてみた。
シナリオとしては以下のとおり。

1. MyPage と YourPage のふたつのページがある
2. MyPage のリンクをクリックすると YourPage へ遷移する
3. YourPage はコンストラクタ引数のパラメータをラベルに反映する

プロダクションコード

• MyPage

class MyPage() : WebPage() {
  override fun onInitialize() {
    super.onInitialize()
    add(Label("myMessage", "Hello!"))
    // クリックすると「YourPage」へ遷移するリンク
    add(object : Link("toYourPage") {
      override fun onClick() {
        setResponsePage(YourPage("Hi!"))
      }
    })
  }
}

• YouePage

class YourPage(private val message: String) : WebPage() {
  override fun onInitialize() {
    super.onInitialize()
    add(Label("yourMessage", message))
    info("Wicket Rocks ;-)")
  }
}

テストコード

• MyPageTest

class MyPageTest {
  /** WicketTester のインスタンス */
  private var tester: WicketTester? = null

  @Before
  fun setUp() {
    tester = WicketTester(WicketApplication())
  }

  @After
  fun tearDown() { }

  /**
   * MyPageが表示可能なことを確認するテスト。
   */
  @Test
  fun canRenderMyPage() {
    // MyPageを開始
    tester!!.startPage(MyPage::class.java)

    // MyPageが表示可能なことを確認
    tester!!.assertRenderedPage(MyPage::class.java)

    // MyPageに「Hello!」と表示されていることを確認
    tester!!.assertLabel("myMessage", "Hello!")
  }

  /**
   * MyPageのリンクをクリックするとYourPageへ遷移できることを確認するテスト。
   */
  @Test
  fun canFlipToYourPage() {
    tester!!.startPage(MyPage::class.java)
    // 「toYourPage」リンクをクリックするとYourPageへ遷移することを確認
    tester!!.clickLink("toYourPage")
    tester!!.assertRenderedPage(YourPage::class.java)

    // YourPageのメッセージが「Hi!」であることを確認
    tester!!.assertLabel("yourMessage", "Hi!")
  }
}

• YourPageTest

class YourPageTest {

  /** WicketTester のインスタンス */
  private var tester: WicketTester? = null

  @Before
  fun setUp() {
    tester = WicketTester(WicketApplication())
  }

  @After
  fun tearDown() { }

  /**
   * コンストラクタ引数を画面反映できることを確認するテスト。
   */
  @Test
  fun canShowConstructorOperand() {
    // コンストラクタ引数に「Unit Testing...」を指定するして起動できることを確認
    tester!!.startPage(YourPage("Unit Testing..."))
    tester!!.assertRenderedPage(YourPage::class.java)

    // コンストラクタ引数に指定した文字列がラベルに反映されていることを確認
    tester!!.assertLabel("yourMessage","Unit Testing...")

    // コンソールに INFO レベルのメッセージが書かれていることを確認
    tester!!.assertInfoMessages("Wicket Rocks ;-)")
  }
}

そのほか、UI部品の有効、無効なども同様の方法でテストできる。

2. Formのテスト

前述の WicketTester から FormTester という、サブミットを含めたFormの操作とテストを行うヘルパークラスを得ることができる。

  /**
   * 正しいユーザー名とパスワードならログオンできることを確認するテスト。
   */
  @Test
  fun canLonginCorrectUserAndPW() {
    // 「form」という名で定義されているFormを、空文字で埋めないよう取得
    val formTester = tester!!.newFormTester("form", false)
    // ユーザー名とパスワードに「user」をセットしてサブミット
    formTester.setValue("username", "user")
    formTester.setValue("password", "user")
    formTester.submit()

    // コンソールにログイン成功が出力されていることを確認
    tester!!.assertInfoMessages("Username and password are correct!")
  }

Form のサブミットには、ほぼ間違いなくその後ろに DB アクセスが発生するだろうけれど、これを JUnit でテストしようと思ったら 既にあるデータを消さないとテスト結果がそれに依存してしまうし、 DB への書き込みをすべてロールバックしないと、ほかの開発データも書きつぶしてしまうことになる。

こういうとき、 DI で DB アクセス部分を分離してやればテストしやすい構造になるんだろうけれど、それは今度試してみよう....。