Проверка Apache Camel

Question

Мы используем Spring для DI и Camel для маршрутизации/обмена сообщениями. Меня попросили настроить некоторые (JUnit) модульные тесты для наших различных компонентов (которые все маршрутизируют сообщения друг к другу по конвейерной схеме).

После взятия гусаков на общем Camel testing документе и Camel-Spring testing дока, похоже, предпочтительного метод модульного тестирования верблюда конечных точек лежит через Spring Framework Test контексте с использованием подклассов объектов, такими как AbstractJUnit38SpringContextTests и сорта.

У меня абсолютно нет опыта с любым из этих API. Поэтому, хотя они делают для интересного чтения, мне сложно помещать их в контекст (каламбур не предназначен).

Как таковой существует несколько начальных понятий я борюсь с:

С одной стороны, когда уместно использовать MockEndpoint, против DataSet, против Test?

Кроме того, Camel-Спринг документ (ссылка выше) приводится следующий пример:

@ContextConfiguration 
public class MyCamelTest extends AbstractJUnit38SpringContextTests { 

    @Autowired 
    protected CamelContext camelContext; 

    @EndpointInject(uri = "mock:foo") 
    protected MockEndpoint foo; 

    public void testMocksAreValid() throws Exception { 

     // lets add more expectations... 
     MockEndpoint.assertIsSatisfied(camelContext); 

     // now lets do some further assertions 
     List<Exchange> list = foo.getReceivedExchanges(); 

     for (Exchange exchange : list) { 
      Message in = exchange.getIn(); 
      ... 
     }  
    } 
} 

Если я даже начала понять этот API, то кажется, что над ним кодом прочитав все сообщения от MockEndpoint по имени mock:foo ... но я не вижу, откуда эти сообщения (откуда они попадают в конечную точку в первую очередь)!

Итак, мой второй вопрос:: Каковы стандартные методы определения конечных точек для «заглушки» (mock)? Например, что, если одна и та же очередь сообщений JMS используется двумя конечными точками, живущими внутри двух разных JAR/WARs: один производитель, а другой - потребитель? В этом случае ProducerComponent (проживает внутри producer.war) является конечной точкой верблюда, которая толкает сообщения на someQueue. И ConsumerComponent (живущий внутри consumer.war) является еще одной конечной точкой Верблюда, которая отправляет сообщения от someQueue.

Каким образом SO организует единичные тесты для обоих компонентов?

Заранее благодарим за любые подталкивания в правильном направлении!

Answer 1

Испытательная глава в Camel book очень хорошая. Я просто расширяю CamelTestSupport, и я использую макет, чтобы быть фиктивным вводом или выходом на маршрут (я не беспокоюсь о Spring или впрыскивании вещей и т. Д.). Существует также множество экзотических вещей, которые вы можете сделать, поместив вещи (я забыл, что они называются) между компонентами маршрута для имитации сбоев и т. Д. Я очень рекомендую вышеупомянутую книгу, это очень ясно и точно.

Для вашего второго вопроса, это зависит от того, как ваши сообщения создаются. Вы можете использовать фиктивную точку для подачи или потребления из очереди (или обоих). Существует много хорошей поддержки в фиктивной точке для проверки сообщений.

CamelTestSupport и его суперкласс имеют много полезных методов для создания сообщений.

Answer 2

Отличная практика для тщательной проверки ваших маршрутов. Ресурсы тестирования верблюдов и Spring, которые вы упомянули, вероятно, являются лучшей отправной точкой.Теперь использование Spring или нет для тестирования зависит также от способа настройки ваших маршрутов, то есть с использованием Spring XML dsl или Java dsl. Очевидно, что CamelSpringTestSupport (или даже AbstractJUnit38SpringContextTests) может быть более подходящим для первого, для последнего вы можете предпочесть просто CamelTestSupport. Теперь на ваши вопросы:

1. Когда целесообразно использовать MockEndpoint, vs DataSet, vs Test? Это не «против», они все выполняют разные роли, и вы должны использовать их вместе, по мере необходимости. Тест не является чем-то конкретным Camel, это просто регулярные тесты JUnit. Camel предлагает некоторые специализации и утилиты для упрощения тестирования (CamelTestSupport и т. Д.). В целом (не всегда) вы использовали бы Camel для системной интеграции, такие как легкие бизнес-процессы или рабочие процессы, используя мощные EIP (шаблоны корпоративной интеграции), определенные Camel, и поддержку бесчисленных протоколов и форматов данных. Во время тестирования вы можете отправлять сообщения на какую-либо конечную точку, но как вы можете убедиться, что ваша обработка правильная, и полученные сообщения являются ожидаемыми? Для этой цели Camel предоставил MockEndpoint, который вы могли бы (во время тестирования) использовать в качестве замены конечной конечной точки. Таким образом, вы можете использовать утверждения, чтобы гарантировать, что полученные сообщения - это те, которые вы ожидали, в правильном порядке, время и т. Д. Посмотрите на properties component на удобные способы замены конечных точек в разных тестовых (или производственных) средах. DataSet - это удобный способ запускать или проверять ряд сообщений.

2. Каковы стандартные методы определения конечных точек для «заглушки»? Обычно работает согласование форматов сообщений и предварительных и пост-условий, то есть вы можете проверить, что производитель создает нужные сообщения независимо от потребителя, и вам даже не нужно использовать один и тот же протокол (вы можете отправить сообщения, например, в MockEndpoint, как указано выше). Это даст вам хорошую уверенность в том, что Производитель делает все правильно. Точно так же вы можете самостоятельно протестировать и потребителя. Скорее всего, при объединении все будет работать, если нет, что-то может отсутствовать в ваших тестах. В большинстве случаев не все может быть протестировано на модуле, и это хорошая практика для проведения интеграционных тестов, которые более похожи на вашу производственную среду.

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