EIP / Test Message

Test Message †

サマリ †

• アプリケーション統合システムの定期チェックの方法として、実際の運用時にテストメッセージを流す仕組みを用意する、という方法。

詳細 †

• Control Busでは、メッセージ処理システムの健康状態を監視する様々な方法を紹介している。
• システムの各コンポーネントは、Control Busに定期的にハートビートメッセージを送ることで、その健康状態を通知できる。
• ハートビートメッセージには、コンポーネントの統計情報を含めることができる。

コンポーネントがメッセージを活発に処理し続けているが、内部の障害によって出力メッセージを破壊してしまっているような場合には、どうするか？

• 単純なハートビートの機構では、このようなエラー状況を検知できない。ハートビートはあくまでコンポーネントの活性状態を送るだけで、アプリケーションメッセージのフォーマットまでは関知しないから。

Test Messageをメッセージの流れの中に忍び込ませて、メッセージ処理コンポーネントの健康状態を確認する。

• Test Messageパターンを構成するコンポーネント：
  1. Test Data Generator -- テスト用のメッセージを生成する。テストデータはテストデータファイルから読み込む固定データでも、ランダムに生成したものでもよい。
  2. Test Message Injector -- テストデータを通常のメッセージの流れの中に注入する。このインジェクタの主な役目は、テスト用メッセージにタグ付けすること。タグ付けには、特定のメッセージヘッダを挿し込む。それができない場合は、最終手段として、特定の値をテストメッセージを表すものとして扱う（例：OrderID = 999999）。
  3. Test Message Separator -- 出力ストリームからテストメッセージの結果を抽出する。通常、Content-Based Routerを使って実装する。
  4. Test Data Verifier -- テスト結果と期待値とを比較し、結果を判定する。場合によっては、オリジナルのテストデータへのアクセスが必要になる。
• テスト対象コンポーネントがReturn Addressをサポートしている場合、Test Message Separatorは無くてもよい。その場合、Test Data Generatorが特定のテストチャネルをメッセージのReturn Addressに設定する。このReturn Addressが実質的にタグの役割を果たす。
• Test Messageは、能動的モニタリング（active monitoring）機構と考えられる。受動的モニタリング（passive monitoring）に対するメリットとして、より深いレベルのテストを実施できる、また、受動的モニタリングをサポートしないコンポーネントもテストできる、ということがある。
• デメリットの1つは、実際の処理ユニットに余分な負荷がかかること。テスト頻度とパフォーマンス影響の最小化のバランスを取る必要がある。もう1つのデメリットは、外部コンポーネントを使用量に応じた課金で利用している場合、余分なコストがかかること。
• 能動的モニタリングはすべてのコンポーネントに適用できるとは限らない。ステートフルなコンポーネントだと、テストデータをDBに書き込んでしまうかもしれない。年間収益報告書にテスト注文が加算されてしまわないように注意！

例：融資ブローカー：信用調査機関をテストする †

• 12章の "Interlude: Systems Management Example" では、Test Messageを使って外部の信用調査機関をモニタリングする。

担当者のつぶやき †

• TDDに比べると、この手の実運用時テストの方法はまだあまり議論されていないし、体系化もされていない印象。インテグレーションシステムだからこその観点だとは思うが、1アプリケーション内でも、実運用中にxUnitのテストが定期的に実行されるようにするなど、応用ができるのではないか。

みんなの突っ込み †