Jason, Actually, there are more scenarios around in memory queues, including running in a desktop app, etc. So yes, I think so. >From my point of view, testing the transport is not a task that you need to do, but integration with the bus is.
On Fri, Oct 23, 2009 at 4:15 PM, Jason Meckley <[email protected]>wrote: > > I have unit tests which reference the service bus and they are easy > enough to test by mocking the service bus. However I don't have any > integration tests ensuring that published messages are consumed > correctly. I use manual testing for that. the system is simple enough > that the number of messages and there routing is easy to track, albeit > grunt work. I can't image this working on a larger scale where > messaging is the backbone of the system. > > What options are available for testing the entire/majority message > workflow? Obviously one option is to use RQ with RSB along with the > disk queues, config files etc. My hesitation with this is the testing > artifacts. config files, disk queues, etc. would all need to be > created/deleted between tests. I'm also not interested in testing the > persistence/threadding/mechanics of messaging. I just want to ensure > that sending message X will be consumed by Consumer/Saga<Y>. > > It would seem an in-memory queue would be ideal for testing similar to > SqLite databases for NH query tests. If an in memory queue doesn't > exist I suppose adding one is as simple as creating a new > implementation of ITransport? > > would an in-memory queue make sense for testing, or is this defeating > the point of testing the message processing? > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
