I'm curious as to the use case for this, so was wondering if you could please elaborate. When you use messaging the communication is asynchronous and therefore the applications are decoupled by nature. So when testing a service like this in isolation I would assume you just need to assert that it publishes / consumes messages correctly, not needing to worry about what happens with the services on the other side of the broker. I think I am missing something?
For plain fire and forget you are correct that async pub/sub is decoupled and in fact while our monolithic app is monolithic it actually is fairly decoupled because of this (e.g. it often is the receiver of its own messages it published).
However there are async request/reply scenarios. Basically a client requesting for a stream asynchronously (this is different than normal request/reply) or even plain request/reply over a messaging protocol (which is done often for better or worse).
For our case it isn't so much that the monolithic app is poor architecture wise (in fact its sort of convenient to have a homogenous fleet of servers) its that the monolithic server makes prototyping a pain (ie some nodejs developer doesn't want to have to boot up the massive Java app).
I think a mirror tool would be useful for this.
I think Hoverfly like thing could be built as a RabbitMQ plugin or I guess you could publish messages to multiple exchanges has one way of recording/mirroring.
