IMO, это в значительной степени зависит от того, что именно вы хотите проверить. Как правило, у вашего потребителя приложения должен быть какой-то метод, например «onMessage», который получает сообщение, и это точка входа потребителя, которая запускает ваши бизнес-потоки.
Если это так, предполагается, что эта точка входа реализована как bean-компонент, вы можете внедрить его в тестовый класс и вызвать его напрямую, минуя весь уровень интеграции rabbitmq.
Одно небольшое предостережение при таком подходе заключается в том, что вам придется исключить все связанные beq mq bean-компоненты из загруженных в тестовый контекст.
Теперь этот подход позволит вам протестировать бизнес-логику одной службы c, что хорошо.
Однако, если вы хотите протестировать, она не дотягивает:
- Протокол сообщений (что сообщения, передаваемые по проводам, действительно верны)
- Интеграция (когда производитель, отправляющий сообщение на какой-либо обмен, потребитель фактически получает сообщение)
- Не функциональные тесты (например, нагрузочные тесты, чтобы убедиться, что потребитель не перегружен под нагрузкой) * 101 6 *
Чтобы решить эти проблемы, вы можете рассмотреть возможность развертывания всей среды с RabbitMQ и сервисами и использовать знания предметной области для правильного утверждения (например, когда потребитель получает сообщение и обрабатывает его - он обновляет БД ) чтобы вы могли в тесте подождать X секунд и опросить базу данных напрямую или вызвать какой-либо API, предоставляемый службой.