今時は、MXUnit なのだろうか。
サイト見ると、「テストユニットを簡単に使えるようにしたいんだっ！」と書いてあるように読めたので、ちょっと試してみよう。
純正の Eclipse プラグインとか Snippet テンプレとかあるので、意気込みは本当かもしれない。
以前作った cfcUnit 用のテストコンポーネントを流用してみた。
assertEqual 関数がデータ型に対して汎用的なものになっていた。
初期化関数 setUp が動かないなぁと思っていたら、MXUnut は、access 属性を public にしなければいけないようだ。
あと、いささか厳しい問題として、フレームワークがらみでつまずいた。
Model-Glue 、ColdSpring 、Transfer の組み合わせでは、
<alias alias="ormService" class="ormService.Transfer" />
という記述をする個所があって、この ormService を bean として扱う。
が、MXUnit は、それを認めてくれないようなのだ。
There is no bean registered with the factory with the id ormService
と言われてしまうのだ。仕方ないので、
<bean id="ormService1" class="transfer.TransferFactory">
<constructor-arg name="configuration">
<ref bean="transferConfiguration" />
</constructor-arg>
</bean><bean id="ObserverInjector" class="&topOfPackage;.model.observer.ObserverInjector" lazy-init="false">
<constructor-arg name="ormService"><ref bean="ormService1" /></constructor-arg>
<constructor-arg name="observer"><ref bean="observer" /></constructor-arg>
</bean>
と記述して、回避することはできた。
まぁ、observerInjector で ormService を引数で渡す書き方をしていたからこういう問題が発生したわけで、必ずしも問題になることにはならないのだろう。
ところで、observerInjector って、なんだったっけか…。
しかし、こんな回避手段を取らない行けないというのは、いただけない。他の回避手段を探さなければ。
Eclipse のプラグインはどうかというと、マッピングの設定をやったり、パスの設定をしてやると、動いてくれた。
この程度の利用では、ユニットテストが簡単にできるかどうかなんてのはわからんな。