Как настроить фиктивную очередь с помощью mockrunner для проверки фильтра xml?

Question

Я использую пакет mockrunner из http://mockrunner.sourceforge.net/ для настройки фиктивной очереди для тестирования JUnit XML-фильтра, который работает следующим образом:

1. устанавливает распознанные свойства для ftp-сервера для размещения и получения входных данных xml, а также для сервера очередей jms, который отслеживает задания. Удаленно ждет сервер, который фактически анализирует XML после получения сообщения очереди.
2. создает удаленный каталог с использованием ftp и запускает подключение к очереди, используя mqconnectionfactory, с указанным адресом сервера очереди.
3. как только новая запись очереди сделана в 2), фильтр ожидает появления нового сообщения очереди, означающего, что задание было выполнено удаленным сервером. Затем фильтр получает измененный XML-файл с FTP-сервера и передает его следующему фильтру.

Тесту JUnit, над которым я работаю, просто нужно эмулировать эту среду, запустив локальный ftp и фиктивный сервер очередей для фильтра, к которому нужно подключиться, затем дождавшись, пока фильтр подключится к очереди, и поместит новый входной файл xml в локальный каталог через локальный ftp-сервер, дождитесь сообщения очереди и затем слегка измените ввод xml, поместите измененный xml в новый каталог и отправьте еще одно сообщение в очередь, означающее, что задание выполнено.

Все учебники, которые я нашел в сети, использовали EJB и JNDI для поиска сервера очередей после его создания. Если возможно, я бы хотел обойти этот маршрут, просто создав ложную очередь на моем локальном компьютере и подключившись к ней самым простым способом, не используя EJB и JNDI.

Заранее спасибо!

Answer 1

Я использую MockEjb , и среди них есть несколько примеров использования ложных очередей, поэтому взгляните на info и пример Надеюсь, это поможет.

Answer 2

Я бы рекомендовал взглянуть на использование Apache Camel для создания тестового примера. Тогда действительно легко переключить ваш тестовый пример с любого из доступных компонентов , и, что наиболее важно, Camel поставляется с некоторыми очень удобными Макетными конечными точками , что делает его очень простым для тестирования сложной логики маршрутизации, особенно с асинхронные операции.

Если вы также используете Spring, то, возможно, начните с тестирования этих модульных тестов Spring с фиктивными конечными точками в Camel , которые позволяют вам вводить фиктивные конечные точки для выполнения утверждений вместе с объектом ProducerTemplate, чтобы сделать его действительно легко отправить ваши сообщения для вашего теста. например см. последний пример на этой странице.

Начните с использования простых конечных точек, таких как конечная точка SEDA - затем, когда вы разберетесь с основной структурой пружины / макета, попробуйте использовать конечную точку JMS или Конечная точка FTP конечные точки и т. Д.