This project is read-only.

Unit Testing the ServiceBus

Aug 4, 2010 at 4:58 PM
Edited Aug 4, 2010 at 5:00 PM

First off, let me say I really like SSB - somewhat better than NServiceBus for my purposes, it just feels more natural.  This could just be that I'm most familiar with ActiveMQ and Spring Messaging.  Anyway, I'd like to be able to wrap some unit tests around the service bus to verify endpoints, producers, consumers, etc... without having a backing transport configured.  I'm having some difficulty figuring out what dependencies there are - and what I might need to stub or mock.  Can anyone point me in the right direction?  Thanks.


Aug 4, 2010 at 4:59 PM
Edited Aug 4, 2010 at 5:00 PM

Just as soon as I hit Send I found 'TestBus' class in the stubs folder - so I think I'm good to go.

Aug 4, 2010 at 6:02 PM
Hi Jon, yes, there are some unit tests inside SSB, but when you want to do unit tests in your own system that is written using SSB then you need to mock some of the interfaces so your code thinks it talks to SSB, but instead it just talks to the mock repository. Since SSB is nicely written with interfaces this is fairly easy to do, the trickiest part for me was injecting the Reply message.
Aug 5, 2010 at 1:03 PM
Edited Aug 5, 2010 at 1:05 PM
Yes, and you can mock anything easily and quickly with this free strongly typed mock framework: Note that testing your handlers should be trivial as you just need to instantiate them and invoke their handle method, providing a sample message. Personally, I have added my own layer over SSB and my code just doesn't know that there is any endpoint or messagebus. I have a simple interface like this: interface IMessagingService { void Send(IEnumerable<Object> messages); IObject Ask(Object request, TimeSpan timeout); } and I have a static class like this: public static class MessagingService { public static IMessagingService Default { get; set; } public static void Send(IEnumerable<Object> messages) { Default.Send(messages); } public static IObject Ask(Object request, TimeSpan timeout) { return Default.Ask(request, timeout); } } That way, anywhere in my code, I can send a message without worrying who does that. And I can mock the simple interface IMessagingService for the unit tests. This mock will accumulate the sent messages in order to let me verify that the code actually sent the message. Also, I have a base class for the handlers that exposes a IMessagingService property that is injected by my wrapper code when instantiating the handler. I did this to ensure that the handler will send messages with the same endpoint the handler belongs to, in the eventual case where there would be several endpoints running. It also makes testing the handler more easily as I can plug a mocked IMessagingService easily. Note that I'm still not using any IoC framework, but if you would you could easily inject your messaging service anywhere you need it, without relying on a global static instance. Hope this helps, Morgan
Aug 5, 2010 at 1:05 PM

That's the same approach I took as well.

Good to see another SSB user. Welcome aboard, jcean8055!