Jason I was using the DDD meaning of the term bounded Context..if I am testing within that same context then I only have to subscribe the messages within that namespacing convention. That reduces the setup time.
On Fri, Oct 23, 2009 at 9:07 AM, Jason Meckley <[email protected]>wrote: > > Oren and Mike good (same) point. I trust RSB is working. I was > thinking that testing the full transport would ensure the consumers > are registered in the container. if that's the case I could test the > container, not the service bus. > > Mike by bound context do you mean the individual saga/consumer. this > would make more sense and be easier to test. > > On Oct 23, 10:39 am, Ayende Rahien <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
