InfoQは最近、Red HatのプリンシパルソフトウエアエンジニアのPete Muir氏に、氏が関わっているJBossの主要プロジェクトのArquillianについて情報交換をする機会を得た。Arquillianは氏が始めたプロジェクトだ。また、ShrinkWrapについても話を聞いた。そして、話題はSeam 3の計画にも及んだ。
統合テストフレームワークであるArquillianはプロジェクトのサイトに書かれている下記の概念によって推進されている。
- コンテナのライフサイクル管理(開始/停止)。
- テストクラスとその依存クラスやリソースを配布可能なアーカイブにまとめる。
- テストクラスの拡張(例えば@Inject、@EJBや@Resourceの注入)。
- テスト用のアーカイブの配置(デプロイ/アンデプロイ)。
- テスト結果と失敗の補足。
また、氏はJBoss Seamプロジェクトにも関わっている。このプロジェクトはJBossのオープンソースの開発スタックだ。そして、氏はJSR-299 (コンテキストおよび依存性注入に関する仕様)の参照実装であるWeldの開発プロジェクトを率いていた。WeldはSeam 3でも大きな役割を果たすだろう。氏はArquillianがSeamの開発にどのくらい適合したかやこのプロジェクトの未来に対する氏の見通しを話してくれた。また、氏はArquillianがどのくらいShrinkWrapを活用したかについても説明した。具体的にはShrinkWrapのAPIを使い、プログラムでJAR、EAR、WARなどのさまざまなファイルフォーマットのアーカイブ/パッケージを生成した経験について話してくれた。
まず、InfoQは氏とArquillianと競合する技術について話をした。
InfoQ: Cargoやもっと古いEJBUnitのような他のJava EE統合テストフレームワークと比べて、Arquillianはどのような点が異なるのか教えてください。
Arquillianはユーザが新しいフレームワークをもうひとつ学習するということに注力せずに、既存の知識で使えるようにすることを念頭において、土台から屋根まで作られています。テストを書くときはJUnit、TestNG、JSFUnitなどの既存のツールをもとにしてテストを書けます。また、(例えば)CDIをテストするとき、テストケースは@Injectや他のCDIの機能をサポートするCDI Beanのように感じられます。このようにArquillianを使い始めるための学習曲線はとても短いです。知っておかなければならないことは既に知っているからです。
通常の方法ではアプリケーション全体を配置してから、それに対してテストを実施します。しかしこの場合、テストに失敗してもどこで失敗したのかわかりません。このようなとき、ShrinkWrapの助けを借りれば、Arquillianが今まで手に入れたことのない機能を提供してくれます。自分が作ったJava EEのテストを通じて細かく制御できるのです。また、ひとつのEJB Beansを、その部分のアプリケーションの挙動を確認することと分離してテストができます。
Arquillianは古いJava EEのコンポーネントモデルのテストがはらむ問題に対する現代的な手法です。しかし、Arquillianの中核部分を見ると、Java EEとArquillianを結びつけるものがないことがわかります。Java EEはArquillianがとることができる形式のひとつにすぎません。Arquillianを使えば、どのような内部テスト用のコンテナでも拡張できます。したがってOSGiやリモートのJVMのようなものも拡張できます。
InfoQ: このプロジェクトではアーカイブ作成や配置作業の単純化を押し進めるためにShrinkWrapをどのように利用していますか。ShrinkWrapはどのような役割を担っているのでしょうか。ShrinkWrapについて教えてください。
Java EEの従来の配置作業ではファイルベースのアーカイブを利用します。EARファイル、JARファイル、そしてWARファイルです。一方、ShrinkWrapプロジェクトは配置作業を操作する単純なAPIを提供することで、ユーザが型通りのビルド作業やファイルのシリアライズを迂回できるようにします。その結果、配置作業はオブジェクトベースになります。その結果、配置作業はファイルではなくオブジェクトに基づくようになります。つまり、ShrinkWrapアーカイブのインスタンスを実行環境に送信することで配置を実現します。
InfoQ: Seam 3ではArquillianはどのような役割を担いますか。
ArquillianはSeamスタックの重要なメンバです。Seamスタックを利用するすべてのアプリケーションに対してエンドツーエンドのテストソリューションを提供するのがArquillianの役割です。また、SeamスタックのすべてのコンポーネントをテストするためにArquillianを大規模に使っていますし、同じようにJBossアプリケーションサーバの機能テストでも使っています。
Javaエンタープライズエディション6の革新的機能(CDIやBean Validationのような)を実現に導いたのはJBossでしたが、仕様については、実装が仕様を満たしているかどうか検証するTCK(Technology Compatibility Kit)が必要でした。この経験があったので、コンテナの内部をテストする新しい手法が必要だということがすぐにわかりました。したがって、まずは初期段階のプロトタイプとしてこの新しい手法をArquillianに組み込み、将来のリリースされるTCKをArquillianに組み込む予定です。
InfoQ: 他のコミュニティがサポートするサーバ(Jetty、Tomcat、GlassFish、Geronimo)や商用サーバ(WebLogic、WebSphere)はどのようにサポートしますか。
Seam 3とArquillianはJava EE 6(完全なJava EE 6かJBoss AS 6のようなウェブ技術)が保証するコンテナや人気のサーブレットコンテナ(TomcatやJettyのような)を完全にサポートします。また、Google Application Engineのようなクラウド環境のサポートも準備しています。Arquillian1.0ではすべての人気アプリケーションサーバの最新リリースをサポートしたいと思います。
最後に私たちは、Arquillianへこれから実装される予定の機能について、またその他のJBossプロジェクトの注目すべき開発について質問をした。氏はArquillianのバージョン1.0をリリースした後の見通しとして、サポート対象のすべてのコンテナでCoberturaを使って、コード網羅率を把握できるようになること、またOSGiを完全にサポートすること、Mavenのアーキタイプをサポートすることを挙げた。また、1.0のリリース以降、JBossプロジェクトは完全なEL統合とそのためのツールを探求する予定だ。そして、JBossはSeam 3へのGWTの統合作業も行っている。氏が言うには、
もうすぐGWTが、ビューレイヤを書くための第一級の選択肢に場面が本当に見られ始めるでしょう。Seam 3へのGWTの統合作業はErraiと統合することに重きを置いています。ErraiはCDIのプログラミングモデルを直接ブラウザ側のコードへ出力するために必要な機能を提供してくれます。とりわけ、CDIのイベント処理と同様にErraiのメッセージングフレームワークに第一にサポートすることで開発者はリッチで非同期処理も可能なウェブベースのクライアントを作成できます。ほとんどのウェブフレームワークにある昔ながらの制約から自由になれるのです。
Erraiはオブジェクトのシリアライズやプッシュ型のメッセージング、ブラウザとの直接的な対話の管理、そして、ブラウザ内で利用するIOC/DIフレームワークを提供します。このフレームワークはJSR-330の仕様を実装し、CDI統合のためJSR-299の仕様の一部分を実装します。この結果、クライアント側のコードはJavaベースでタイプセーフになります。サーバもクライアントも共通のAPIを真の意味で共有できます。