Модульное тестирование Apache-Camel JmsReply для прохождения маршрута - PullRequest
Новая
       15

Модульное тестирование Apache-Camel JmsReply для прохождения маршрута

0 голосов
/ 29 апреля 2019

У меня есть следующий пример потока маршрута, где я получаю сообщение jms, создаю запрос веб-службы и затем отвечаю на JMSReplyTo ответом веб-службы: 

    from("{{jms.input.queue}}).routeId("Receive JMS Message")
        .to("direct:start");


    from("direct:start").routeId("Build & Send Http Request")
            .bean(processRequest)
            .to("{{http.endpoint}}")
            .to("direct:processResponse");

    from("direct:processResponse").routeId("Build XML Response")
            .convertBodyTo(String.class)
            .bean(processResponse);

Я успешно проверил мои процессы модульным тестированием, но теперь я хочу провести модульное тестирование моего маршрута. Вместо того, чтобы сервер EMS работал во время тестов, я начал со второго маршрута: 

  camelContext.getRouteDefinition("Build & Send Http Request").adviceWith(camelContext,
            new AdviceWithRouteBuilder() {
                @Override
                public void configure() throws Exception {
                    interceptSendToEndpoint("http://*")
                    .skipSendToOriginalEndpoint()
                    .setBody("Hello");
                }
            });

@Test
@DirtiesContext
public void RouteFlowTest() throws Exception{

    Map<String,Object> jmsHeaders = new HashMap<>();
    jmsHeaders.put("Auth","helloWorld");
    jmsHeaders.put("JMSReplyTo","sample");

    String jmsBody = "Help Me"
    incomingJmsRequestMessage.sendBodyAndHeaders("direct:start", jmsBody, jmsHeaders);

}

а как теперь утверждать обмен после выполнения bean-компонента processResponse?

Или есть способ протестировать с первого маршрута и удовлетворить JMSReplyTo без фактического запуска сервера EMS?

1 Ответ

0 голосов
/ 29 апреля 2019

Поскольку вы уже создаете маршрут, вы можете добавить распространение к фиктивной конечной точке в своем совете по маршруту, например: 

this.weaveAddLast().to("mock:done");

, который просто добавляет определение .to("mock:done") в конец вашего "Build & Send Http Request" маршрута. Из данного постановки задачи немного неясно, что на самом деле делает .bean(processResponse);. Вы также можете добавить это ложное распространение в конечной точке к маршруту "Build XML Response", и в этом случае вам понадобится дополнительное определение маршрута.

Далее, вы можете позволить Camel вводить фиктивную конечную точку через 

@EndpointInject(uri = "mock:done")
private MockEndpoint done;

или определите его вручную внутри теста с помощью: 

MockEndpoint done = camelContext.getEndpoint("mock:done", MockEndpoint.class);

Эта фиктивная конечная точка может использоваться для определения определенных ожиданий , так что вы ожидаете, что одна конечная точка получит одно сообщение 

done.expectedMessageCount(1);
...
// invoke your route here
template.sendBody(...);
...
done.assertIsSatisfied();

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

Exchange exchange = done.getExchanges().get(0);
...

Если вы используете Camel поверх Spring (Boot), вы также можете прочитать, как тестировать Camel с включенным Spring

...