ok, that's different than what I was thinking. thanks for the clarification.
On Oct 23, 2:04 pm, Mike Nichols <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
