views:

239

answers:

2

I would like to create a series of automated unit tests for an MSMQ application I am writing. As I see it, the challenge is how to accommodate the event handlers from the test method. That is, I send a message from the test method and need to return a result back to that test method that the message has been received and handled. I have no clue as to how to accomplish this and any direction would be greatly appreciated.

+1  A: 

Typically a unit test should isolate the method being tested. I'm not familiar with MSMQ but you would normally create a mock object and pass that to your production method. Then you can sense what the method did to the mock object to verify its behaving correctly and send the expected response. The production method won't know the difference. Unit testing is more to ensure your methods are behaving as expected in isolation.

Sound's like what your looking for is an integration test. You can still use unit testing frameworks to accomplish this but I wouldn't include them in an automated build. I would move them to a dedicated test machine(s). Unit tests typically halt a build as they indicate a class or method that isn't behaving as expected. Where as integration tests indicate and methods or classes aren't interacting with each other as expected.

codeelegance
Thanks - I've completed tests on the methods, but I guess what I am looking for is more of an integration test. Still, I would like to be able execute these tests ala NUnit where I have a suite of items I expect to satisfy my test conditions.
David Robbins
NUnit should work fine for this. Integration testing is much more complex than unit testing though. At a minimum you'll need instances of the sending and receiving classes and some way of capturing the state of each. This may involve subclassing your production classes and changing access modifiers to expose fields usually kept private. It really depends on the design of your application.
codeelegance
A: 

Are you looking for a way to write unit tests where the system under test thinks it's receiving events from a queue, but you don't want to use a real queue during the tests?

Check out Rhino Mocks. It lets you create a mock version of your queue interface, and then raise events from it during the test. Some pseudo code to test the Requester.DoSomething() method might look like this:

// SETUP
MockRepository mocks = new MockRepository();
IQueue mockQueue = mocks.StrictMock<IQueue>();

queue.Received+=null;//create an expectation that someone will subscribe to this event
LastCall.IgnoreArguments();// we don't care who is subscribing
IEventRaiser raiseReceivedEvent = LastCall.GetEventRaiser();//get event raiser for the last event, in this case, Received
Expect.Call(mockQueue.Send).Return(msgId);
mocks.ReplayAll();

// EXEC
Requester req = new Requester(mockQueue);

// We expect this method to send a request to the mock queue object.
req.DoSomething();
// Now we raise an event from the mock queue object.
raiseReceivedEvent.Raise(eventArgs);

// VERIFY
// we would probably also check some state in the Requester object
mocks.VerifyAll();

Check out the Rhino mocks wiki for all the details.

Don Kirkby