Pluginのテストを自動化するには(その2:テスト用のプラグインを作るには)
テスト用のプラグインを作るのは簡単なように見えますが、実は難解な作業です。本体のプラグインを必須プラグイン(Required-Bundle)に設定すれば一見クラスの参照関係が整うので、動作するように見えます。しかし、実際はプラグイン同士の依存関係が解決されていない事がよくあります。よく起しやすいのは循環参照です。
循環参照とは
循環参照はプラグイン同士の依存関係が循環している状態を指します。もっとも単純な例で記述すると、プラグインＡをビルドするためにはプラグインＢが必要で、プラグインＢをビルドするためにはプラグインＡがビルドされていなければならないという関係です。プラグインが二つの例ではなかなかおきない循環参照ですが、プラグインの数が増えてきて、かつテスト用のプラグインを作成する関係になると話が変わってきます。気付くとテスト用のプラグインがアサーションのときに元のプラグインの依存するクラスを参照したい場合が出てくるでしょう。それを補助するテスト用のプラグインなどを作り始めると、気付かないところで循環参照が起きていることがよくあります。そもそもプラグイン同士の依存関係が解決していないと、プラグインを開発環境でビルドがうまくいきません。起動時にうまくビルドが行かなかった場合は、プラグインの依存関係を見直すことが解決への近道です。
循環参照を回避する方法としてRequired-Bundleとして宣言している依存関係をやめて、Import-Packagesを使って必要なパッケージを宣言することが上げられます。Plug-inごとに必要なパッケージを宣言することになるので、循環参照のリスクはかなり低減されますが、あるパッケージを参照したくなるたびに宣言しなければならないのでかなり作業が煩雑になるでしょう。また別の問題も発生します。
実はプラグインごとにクラスローダーが稼動しているため、プラグインをまたいだリソースの取得は基本的にできない構造になっています。（僕はこれは構造的にプラグインごとの依存性を下げるための処置だと理解しています。プラグインが稼動しているOSGiはネットワークを意識したつくりになっているため、基本的に一つのプラグインで一つの環境を構成しています。しかしクラスファイルが例外になっているので、リソースもそうなっててもおかしくない気もします。）リソースの参照が基本的にできないと何が困るか、というとテスト用の設定ファイルを用意して、テスト時はそちらのファイルを読み込ませようとしても対応できないのです。それはなぜかというと、既存のほとんどのライブラリはクラスローダーからリソースを取得するものがほとんどです。そのためプラグインをまたいでしまうとリソースの取得が出来ません。
これを回避するにはテスト用のプラグインをplug-inとして作成するのではなく、本体のプラグインのfragmentとして作成すると良いというアイディアが公開されています。fragmentは本体のプラグインとの差分として読み込まれるため、同一のクラスローダーにロードされます。リソースの取得が出来なかったり、プラグインの依存関係が解決できていないということはテスト用のプラグインを作成したときと話が変わってきます。
次回はこの点をふまえて、Eclipseの外から実装したテストプラグインのテストを実行してみるというのをやってみます。あと、図とかは都度時間が出来たら追加してもっと推敲したものを公開する予定です。（絶対読みにくいですよね。ごめんなさい。）
