現在のアプリケーションでは、操作コントラクトを一方向としてマークする必要がある WCF netMSMQBinding を使用しようとしています。
また、Fitnesse をテスト エンジンとして使用しようとしています。このテスト ケースでは、シナリオをエンド ツー エンドでテストする必要があります。これは、メッセージが配置されるとすぐに返されるため、一方向操作を使用できないことを意味します。 queue とfitnesse は結果をアサートしようとしますが、実際のメッセージではまだ処理されている場合とされていない場合があります。したがって、一方向の操作を使用する場合は、実行が完了するまで何らかの方法で待機する必要があります。
試したアプローチ/研究中..
構成を読み取ることにより、ホスティング時に OperationDescription を変更します。これにより、Fitnesse IsOneWay が False でホストされているが、実稼働環境では IsOneWay が True であり、その後、実稼働環境でのみユーザー MSMQ バインディングをテストし、tcp または netnamedpipe を使用するようになります。
カスタム ServiceHost を作成し、Service を開く前に OperationDescription を変更しようとしましたが、OperationDescription クラスの IsOneWay は読み取り専用プロパティであり、.Net Framework コードを見ると、メッセージの数が返されます。私の意見では、サービス ホストの CreateDescription 操作をオーバーライドし、カスタム実装を提供する必要があります。そうみたいです
メッセージが処理されるまで何らかの方法で待機するモニター フィクスチャを Fitnesse に作成します。
アプローチ 1: MessageId と完了ステータスを格納するカスタム db テーブルを作成し、各メッセージ処理の最後にそのテーブルにレコードを入力します。これで、fitnesse フィクスチャはテーブルをポーリングし、実行が完了するまで待機することができます。
アプローチ 2: 何らかの方法で MSMQ をポーリングし、メッセージがいつ処理されるかを把握します。どうすればうまくいくか、まだまだ研究中です。
現在のアプローチまたは新しいアプローチの指針を提案してください。