JUnitのTestRunnerクラスとTestResultクラスに関する補足

JUnitのTestRunnerクラスとTestResultクラスに関する補足

　今回の事例の中心は、TestRunnerクラスとTestResultクラスでした。Observerパターンに関係する部分に焦点を当てて説明しました。そのため、関係のない部分の説明は割愛しています。実際は図3-1を見てわかるように、もう少し複雑な構成で実装されています。

　TestRunnerクラスは、標準でCUI版とGUI版が用意されています。それぞれBaseTestRunnerクラスのサブクラスであり、BaseTestRunnerクラスはTestListenerインターフェースを実装しています。TestListenerインターフェースはObserverパターンのObserver役になり、BaseTestRunnerクラスのサブクラスはConcreteObserver役になります。一方、TestResultクラスは、ObserverパターンのSubject役であり、ConcreteSubject役でもあります。

　Observerパターンを適用したことで、JUnitの実装に影響を及ぼすことなく、利用環境に応じてCUI版やGUI版のテストランナーやEclipseのJUnitのビューへ、切り替えが簡単にできるのです。また、TesRunnerクラスは、TestResultクラスからユニットテストの実施状況をリアルタイムに通知を受けることができます。それによってTestRunnerクラスは、プログレスバーでテストの実施状況を表示できるのです。

データ（ロジック）とビューの分離

　今回紹介したObserverパターンは、Subject役が複数のObserver役に対してリアルタイムに通知を行うものでした。Observeの本来の意味は「観察」ですが、実際はSubject役より状態変化の通知を受けることで把握しています。Subject役の通知先が固定に決められないときやクラス間の結合度を弱くしたいときに効果を発揮します。Observerパターンは、クラス間のやりとりが一見複雑に見えますが、メソッドの意味や流れを1つ1つ確認していくことで理解できるはずです。

　このほかにObserverパターンは、MVCパターン（Model/View/Controller）を用いたプレゼンテーション・フレームワークでもよく利用されています。MVCパターンは、データやロジックなど表示形式にとらわれないModelと、Modelの持つ情報をどのような形式で表示するか決定するViewにわけて設計／実装を進めていきます。ModelはViewに依存するような実装をしてはいけません。またModelから見てViewは1つ以上存在します。ObserverパターンのSubject役とObserver役に関係が似ていますね。ちなみにMVCパターンは、Observerパターンのような小さなデザインパターンをいくつか組み合わせて実現しているパターンのため、粒度的にもデザインパターンというよりはソフトウエア・アーキテクチャに近いものです。

　次回は、Factory MethodパターンとAdapterパターンの組み合わせの事例を紹介します。それでは、次回をお楽しみに！

【参考文献】
Erich Gamma, Rechard Helm, Ralph Jonson, John Vlissides『オブジェクト指向における再利用のためのデザインパターン』ソフトバンククリエイティブ（発行年:1999）
結城　浩『Java言語で学ぶデザインパターン入門』ソフトバンクパブリッシング（発行年:2001）
Vincent Massol,Ted Husted『JUnitインアクション』ソフトバンクパブリッシング（発行年:2004）
「JUnit.org」（http://www.junit.org/）（アクセス:2009/04）