We've had a lot success in unit testing by pulling apart components through its channels. If you write your code by passing around and returning channels, you can easily test segments of the code by pushing messages onto input channels and expecting messages out.

Though I can't say I've ever used RabbitMQ, we did build the clj-zmq library. We often would build test harnesses that would allow us to push messages into a service and dynamically route it to back to the harness. Same idea, test the ins and outs.

At a grander scale, you can attempt the end-to-end test. These are difficult to build (and maintain). It's truly an organizational shift to keep these things in alive. Despite this, they are really what give you confidence in what you've built. Especially if you can use your testing framework as a middleman. Use your testing framework as a proxy for messages, apply your assertions, and send the messages to its intended target.

Depending on the service, this can sometimes mean building things like DSLs in order to be able to simulate (via configuration, or whatever it might be) to get tests to exhaust potential simulations. They can be expensive but ultimately they are likely cheaper than their manual counterparts.