How to Test OneWay WCF Operations with Fitnesse

Question

In our current application we are trying to use WCF netMSMQBinding which needs an Operation Contract to be marked as One Way.

We are also trying to use Fitnesse as our test engine, In our test case we need to test the scenario end to end, which means that we can not use One Way Operations, because they will be returned as soon as the message is placed in queue and fitnesse will try to assert the results but in actual message may or may not have been processed yet. So if we use one way operations then we need to wait somehow till its execution is finished.

Approaches tried/Researching on ..

1. Change OperationDescription at time of hosting by reading configuration, so that when Hosted in Fitnesse IsOneWay is False, but in production IsOneWay is True and then user MSMQ binding only in production and for testing use tcp or netnamedpipe.

   We tried to create custom ServiceHost and change OperationDescription before Service is opened, but in OperationDescription class IsOneWay is read only property and by looking at .Net Framework Code, it returns count of Messages. In my opinion, i have to override CreateDescription operation of Service Host and have to provide custom implementation. It seems

2. Create a Monitor Fixture in Fitnesse which would some-how wait till the message is processed.

   Approach 1: Create custom db table which stores MessageId and completed status and at the end of each message processing enter the record in that table. So now fitnesse fixture can just poll the table and wait till the execution is done.

   Approach 2: Somehow poll MSMQ and know when a message is processed. We are still re-searching how to make it work.

Please suggest any pointers for current approaches or any new approach.

Answer 1

I suggest #2 is better. With #1, you're no longer testing the system as it will run in production. I assume you want to test for some business condition after the message is processed. Can you poll for this business condition to be true? I think this is a better approach than 2.1 or 2.2 where you are polling for a technical condition.