Integration tests with RSB

[Jason Meckley]

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?

[Mike Nichols]

I had asked something similar a while back. I guess I'd make sure you are testing your code and not the behavior of RSB itself...which is what this sounds like :

" I just want to ensure  that sending message X will be consumed by Consumer/Saga<Y>."

But this is one of those gray areas that could go either way I think. The downside of testing a message lifecycle is actually the setup time required for subscriptions but I started testing against specific Bounded Contexts to get around this...a lot less messages to subscribe.

[Ayende Rahien]

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.

[Jason Meckley]

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 <aye...@ayende.com> 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.
>

[Mike Nichols]

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.

[Jason Meckley]

ok, that's different than what I was thinking. thanks for the
clarification.

On Oct 23, 2:04 pm, Mike Nichols <nichols.mik...@gmail.com> 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.
>