Unixな話を中心に。最近は雑多な内容が多かったりして...。ユニットテストを簡単に実行できるようになっている。シナリオとしては以下のとおり。MyPageが表示可能なことを確認するテスト。MyPageのリンクをクリックするとYourPageへ遷移できることを確認するテスト。コンストラクタ引数を画面反映できることを確認するテスト。}}そのほか、UI部品の有効、無効なども同様の方法でテストできる。いう、サブミットを含めたFormの操作とテストを行うヘルパークラスを得ることができる。正しいユーザー名とパスワードならログオンできることを確認するテスト。書き込みをすべてロールバックしないと、ほかの開発データも書きつぶしてしまうことになる。アクセス部分を分離してやればテストしやすい構造になるんだろうけれど、それは今度試してみよう....。いうdependencyが必要。使うには継承したうえで実装しなければならない処理がある。getWebSessionClass()アプリケーションで使うセッションストアのクラスを返す上記のユーザーガイドからの抜粋をKotlinで書いてみると、こんな感じになる。途中で認証をはさみたいときは「トップページとかは普通に見れるようにするが、あるページは会員だけに見せたい」といった場合、途中でユーザー認証を行い、認証に成功したらユーザーがもといたページに戻す、といった処理をやることになる。いった場合は、以下の二つの方法をとる、とのこと。内部的にスローされてページ遷移するので、以後の処理は行われなくなる。Wicketでの認可いわゆる処理に対する権限チェックである。認可に関する処理の一つ。「ログインしているか否か」も、認可の範囲に入る模様。アクションが許可されているかどうかを返す。指定されたコンポーネントをインスタンス化できるかどうかを返す。リクエストのパラメータが、リソースへのアクセスが許可されているかどうかを返す。すべてを許可するALLOW_ALLという実装のほか、ページ単位のチェックを行う規定処理がすでに組み込まれている。それぞれ、用途的には以下のような違いがある。...}....といった感じになるはず。}}...といった具合になるはず。いうイベントリスナがあるので、これの中で処理する。}ロールの検証を追加するなら、こんな感じになるはず。}まぁ、このあたりはデフォルト実装でもどうにかなるレベルなので、やるかどうかはケースバイケースか。"mydbadmin")と、ソースコードに直接書いていたけれど、実際の運用を考えるとDBの接続先設定とプロダクションコードは極力分離したいところ。幸いにも、Mavenで作ったプロジェクトのアーキタイプにはJettyがdependencyに組み込まれていて、test側に開発サーバとしてJettyを起動するときの処理が最初から入っている。設定を書いてやれば、理屈の上ではプロダクションコードからDBの接続先設定を分離できることになる。前置きが長くなってしまったけど、Mavenで依存に入っているJettyにDataSourceを設定するのに結構苦労をしたので、その時の備忘録的なメモを書いてみる。やること(というかやったこと)やったことをざっくりまとめると、以下のとおり。依存とプラグイン設定を追加なにはなくともdependencyに必要なライブラリを入れなければならない。今回はコネクションプールライブラリを挟む方針で、高性能を謳っていることで話題のHikariCPを使ってみることにする。</dependency></dependencies<Jettyがtestスコープで動くので、コネクションプールとJDBCドライバもそれに合わせておく。次に、JettyがHikariCPとconnector-jを扱う設定を読み込めるようにするのだけど、これはMavenプラグインの設定をいじる必要がある。追加するとこんな感じになるはず。