私はメッセージングシステムの統合テストを書いています。ほとんどのテストは、フローのさまざまな段階で、メッセージとそのさまざまなコードパスのカウントをエンドツーエンドで収集します。私が現在行っているテストは、これらのメッセージングコンポーネントに多くのがあり、メッセージの処理時にそれらをインクリメントするという点で、非常に煩わしくなりすぎていpublic static AtomicIntegerます。テストは、これらのカウントでアサートします。
最悪の部分は、バグを追加しがちな製品にデプロイするときに、これらのカウンターを削除する必要があることです。
クラス全体にカウンターを詰め込む必要なしに、これらのコンポーネントを通過するメッセージの数を取得するようにテストを設計するにはどうすればよいですか？私は、実際のコンポーネントをサブクラス化し、メソッドをオーバーライドし、サブクラスメソッドのカウンターを移動し、これらのサブクラスをテストで使用することを考えていました。より良い設計に関する他の考えはありますか？
テストでのみ使用されるstatic でコードを分散AtomicIntegerさせることは、確かに悪い考えです。私がお勧めするいくつかのアプローチを次に示します。
ミドルウェアで利用可能なjmxまたはその他の監視メカニズムを使用して、非侵襲的な方法でメッセージ数を読み取ります
すべてのコンポーネントにリスナーをインストールする可能性を追加します。実稼働環境ではnull、または null オブジェクト パターンを使用し、テストでは、いくつかの単純なリスナーをインストールして、呼び出し/メッセージをカウントします。ディがお手伝いします。
上記と同様に、 aopまたはその他の計測技術を使用します。
副作用と出力をテストしてください！フロー内の正確なメッセージを推測するのではなく、全体的な結果が正しいかどうかを確認してください。このようにして、テストはより柔軟になり、テスト対象に集中できます。残念ながら、何かが壊れると、デバッグに時間がかかります。
少し前に、まったく同じようなシナリオに対処しなければなりませんでした。いくつかのコンポーネントでいくつかのメッセージを処理してから、それらを他のコンポーネントに渡しました。私はこのデザインを思いつきました：
notifyすべてのコンポーネントは、受信したメッセージを通知して他のコンポーネントに渡すために使用されるメソッドを持つインターフェースを実装します