Aspectのデバックってどうしたらいいんだろう

AspectJなんかを使ってプログラミングをしていると、Aspect自体のデバッグをどうしたらよいのかわからないことがでてきました。

通常のクラスのテストであれば、すっかり有名になってしまったJUnitを使えば大概のことはおさえられるようになりましたが、現在のところAspectに対応するJUnitのようなツールはないのです。さて、どうしたものかといろいろ考えてみました。

† なぜAspectのデバッグなのか

Aspect指向に慣れてくると、より汎用的（抽象的）なAspectを作りたいと思うようになります。このあたりはOO^*1の発想と一緒ですね。さらに、ゆくゆくはそれらを集めてライブラリのようなものにしていきたいと思うのが、開発者のサガとしては自然でしょう。

ここでの問題はAspectを汎用にすれば汎用にするほどAspectが織り込まれる対象となるクラスは多くなるということです。つまり、Aspectに変更を加えると広範なクラスに変更を加えたのと同じことになるので、大規模なプロジェクトの場合にはリグレッションテスト ^*2のコストがとんでもないことになってしまいます。

そもそも、AOPの目的は横断的関心事をモジュール化するためにあるので、テストも横断的関心事のみで行えないと、AOPの意義自体が吹っ飛んでしまいます。でも、これを支援するようなツールはでは存在していないようです^*3。まぁ、スライシング云々という手段があるということは知っているのですが、あまりスマートな手段でないような気がします。

テストがされていないプログラムに価値がないのは自明ですが、僕のポリシーとしてはテストできない（やりにくい）プログラムはその時点で価値が半減していると思っているのですが、どうでしょうか。

AOPはまだまだこれからの技術で、AspectJは確かに面白いですが、僕の中ではまだテストしにくいプログラムです。早く実戦投入したいのもやまやまですが、このせいで実戦投入をためらってしまっています。

AspectJを使っている世の中の人はデバックをどうやっているんでしょうか。まだ、Logの取得のようなプログラムに対して差しさわりのないような処理だけを行っているのかな。

† Aspectのテストって何だろう

Aspectのテストでやらなきゃいけないことですぐに考えつくはこの２つでしょうか。

　・織り込まれる先のモジュールに対して、不必要な影響を与えていないか。
　・Aspect本体(Advice)に書かれた内容が正しく機能しているか

前者については織り込まれる先のモジュールに影響を与えないようなAspectであればテストケースがそのまま使えるので簡単でしょう。でも逆に織り込まれる先のモジュールに対して積極的に影響を与えるようなAspectを考えるとテストケースも変化してしまうのでかなり難しそうです。

後者についてはもっと厄介そう。例えばLogを出力するAspectを考えた場合に、Logがきちんと書かれたかどうかについて調べたいということなんですが、ログを書くという行為は、織り込まれる先のクラスにとってはメタレベルの話になるので、そのクラスはログのことについて知る由もないわけです。つまり、通常ではテストのやりようがない。

ここまで書いて、頭が痛くなってきました。。。。

† 問題山積ですね

研究室のAspectチームとDebug&Testチームはこれについて何かたくらんでいるようです。何か名案がでるのでしょうか。楽しみです。