Mule Функциональные тесты - полностью смущены

Question

У нас есть приложение Mule с 6 или семью потоками с примерно 5 компонентами на поток. Вот настройка. Мы отправляем запросы JMS в очередь ActiveMQ. Мул слушает это. Основываясь на содержании сообщения, мы направляем его соответствующим потокам.

<flow name="MyAPPAutomationFlow" doc:name="MyAPPAutomationFlow"> 
     <composite-source> 
      <jms:inbound-endpoint queue="MyAPPOrderQ" connector-ref="Active_MQ_1" doc:name="AMQ1 Inbound Endpoint"/> 
      <jms:inbound-endpoint queue="MyAPPOrderQ" connector-ref="Active_MQ_2" doc:name="AMQ2 Inbound Endpoint"/> 
     </composite-source> 
     <choice doc:name="Choice"> 
      <when expression="payload.getProcessOrder().getOrderType().toString().equals(&quot;ANC&quot;)" evaluator="groovy"> 
       <processor-chain> 
        <flow-ref name="ProcessOneFLow" doc:name="Go to ProcessOneFLow"/> 
       </processor-chain> 
      </when> 
      <when.... 
      ........... 


     </choice> 
    </flow> 


<flow name="ProcessOneFLow" doc:name="ProcessOneFLow"> 
     <vm:inbound-endpoint exchange-pattern="one-way" path="ProcessOneFLow" responseTimeout="10000" mimeType="text/xml" doc:name="New Process Order"/> 
     <component doc:name="Create A"> 
      <spring-object bean="createA"/> 
     </component> 
     <component doc:name="Create B"> 
      <spring-object bean="createB"/> 
     </component> 
     <component doc:name="Create C"> 
      <spring-object bean="createC"/> 
     </component> 
     <component doc:name="Create D"> 
      <spring-object bean="createD"/> 
     </component>  
</flow> 


<spring:beans> 

    <spring:import resource="classpath:spring/service.xml"/> 
    <spring:bean id="createA" name="createA" class="my.app.components.CreateAService"/> 
    <spring:bean id="createB" name="createB" class="my.app.components.CreateBService"/> 
    <spring:bean id="createC" name="createC" class="my.app.components.CreateCService"/> 
    <spring:bean id="createD" name="createD" class="my.app.components.CreateDService"/> 
      ...... 
      ...... 
</spring:beans> 

Теперь я не уверен, как я могу написать с ними функциональные тесты.

Я просмотрел документацию по функциональному тестированию на веб-сайте Mule, но там у них очень простые тесты.

Функциональное тестирование не должно делать фактические обновления бэкэнда с использованием DAO или уровней обслуживания или это просто расширение модульных тестов, где вы макетируете служебный уровень?

У меня возникла идея - он может принять запрос и использовать сервер Mule inmemory для передачи запроса-ответа от одного компонента к другому в потоке. Также обратите внимание, что конечная точка исходящего трафика для любого из наших потоков отсутствует, поскольку в основном потоки потоков Fire и Forget и обновления состояния управляются обновлениями БД, которые выполняют компоненты.

Также почему мне нужно создавать отдельные файлы xml-файлов mule для тестов? Если я не тестирую поток xml, который будет фактически развернут на Live, в чем смысл этого тестирования? Я создаю отдельные xml-конфиги только для тестов, которые несколько поражают цель для меня ... Может ли какой-нибудь эксперт любезно разъяснить немного больше и указать на примеры тестов, аналогичные тем, которые мы используем.

PS: компоненты внутри Mule зависят от внешних систем, таких как веб-службы, базы данных и т. Д. Для функциональных тестов нам нужно иметь эти запущенные или мы должны издеваться над этими сервисами/Db Access?

Answer 1

Функциональное тестирование вашего приложения Mule ничем не отличается от тестирования любого приложения, которое зависит от внешних ресурсов, таких как базы данных или брокеров JMS, поэтому вам нужно использовать те же методы, которые вы бы сделали со стандартным приложением.

Обычно это означает, что ресурсы выделяются с реализациями в памяти, такими как HSQLDB для баз данных или временным брокером ActiveMQ в памяти для JMS. Для приложения Mule это подразумевает модульную настройку, поэтому «живые» транспорты определяются в отдельном файле, который вы заменяете на тот, который содержит варианты в памяти во время тестирования.

Чтобы проверить правильность взаимодействия Mule с ресурсом, вы можете либо прочитать ресурс напрямую, используя его Java-клиент (например, JDBC или JMS), что хорошо, если вы хотите, чтобы у чисто не-Mule-клиентов не было выдавать сообщение о том, что отправил Mule, или использовать MuleClient для чтения из этих ресурсов или создавать потоки, которые потребляют эти ресурсы, и передавать сообщения на <test:component>.

FYI Эти различные методы объясняются и показаны в главе 12 от Mule in Action, second edition.

Answer 2

https://blog.codecentric.de/en/2015/01/mule-esb-testing-part-13-unit-functional-testing/

https://developer.mulesoft.com/docs/display/current/Functional+Testing Пожалуйста, обратитесь это ссылки Как вы можете видеть, это обычный тест JUnit расширения класса FunctionalMunitSuite. В нашем тесте нужно сделать две вещи:

Подготовьте объект MuleEvent как вход в наш поток. Мы можем это сделать, используя предоставленный метод testEvent (Object loadload). Выполнить runFlow (String flowName, MuleEvent event) метод, определяющий имя потока для проверки на событие и событие, которое мы только что создали на первом этапе.