Observerパターンの事例

デザインパターンでランチャーを作成する

　前回は、Template Methodパターンの事例を紹介しました。抽象クラスと具象クラスの継承関係をうまく活用したパターンでしたね。日ごろからよく使う基本的なテクニックなので、マスターしておきたいパターンの1つです。

　今回は前回と同様に、JUnit3.8.1（http://www.junit.org/）を事例に、Observerパターンを取り上げます。ObserverパターンはGoFのデザインパターンの1つで、振る舞いに分類されるパターンです。Observerとは「観察者」という意味です。観察対象になる被験者（Subject）の知りたい状態の変化を把握するのに有効なパターンです。ただし、観察といっても観察者が被験者を常に観察しているわけではありません。その実態は、被験者の状態が変化したときに観察者はその変化の通知を受けることで把握しています。

　JUnitでは、ユニットテストを実施するランチャーが用意されています。そのランチャーでは、実施状況を把握するのにObserverパターンが利用されています。観察者はBaseTestRunnerクラスから派生したTestRunnerクラス、被験者はTestResultクラスになります。JUnitでは、この2つのクラスの協調関係によって、ユニットテストの実施状況を把握しています。

　今回はこの2つのクラスに焦点を当てて、どのようにObserverパターンが適用されているのか、どのような効果があるのかを分析して理解を深めます。

必要なランチャーを考える

　前回はテスティングフレームワークが存在しなかったころのテスト手法の説明をしました。そのテスト手法では、テスト実施に関して次のような問題を抱えていました。

　・実施したテストケースの数がわからない
　・成功／失敗のときのステータスの表現が統一されていない
　・実施結果から問題個所の特定が難しい

　今回はこれらの問題を解決するランチャーを作成します。


■実施結果のステータスは3つある
　テストケースには、テスト対象が仕様どおりに実装されていることを確認するためのコードを実装します。仕様どおりの場合は成功、そうでない場合は失敗と判断します。また、仕様の確認とは関係のない処理（テスト前、テスト後の処理）のバグでテストが中断するような場合はエラーとします。

　よって、テストケースの実装が正しい場合、実施結果のステータスは次の3つになります。
　・成　功……仕様どおりである
　・失　敗……仕様どおりでない（テスト対象のバグ）
　・エラー……想定外のエラーが発生した（テストケースのバグ）


■テストの実施状況を把握する必要がある
　テストの実施状況を把握するためには、テストの進み具合や失敗／エラーの原因を知る必要があります。テストケースごとにテストの開始と終了のタイミングを知ることができればテストの進み具合を把握できます。また、失敗やエラーが発生したタイミングを知ることができれば、それらの原因を残すことができます。

　次のタイミングで必要な情報の収集や表示情報の更新ができるような仕組みを用意します。

　＜タイミング＞　　　　　＜処理内容＞
　テスト開始時　　　→　　テストケースの件数の更新
　テスト終了時　　　→　　今回は何もしない
　失敗時　　　　　　→　　失敗の原因の保存と件数の更新
　エラー発生時　　　→　　エラーの原因の保存と件数の更新


■こんなランチャーを作成する
　まとめると、次のような責務を持ったクラスが必要になります。今回は、この2つのクラスを用いてランチャーを作成します。

●TestRunnerクラス
　・ユニットテストの開始指示を行う
　・ユニットテストの実施状況を把握し、表示情報を更新する

●TestResultクラス
　・ユニットテストの実施結果を収集する
　・テストケースごとに次のタイミングで表示情報の更新ができるような仕組みを用意する
　　テスト開始時
　　テスト終了時
　　失敗時
　　エラー発生時