Apache Camel Тестирование

Question

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

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

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

Таким образом, есть несколько начальных понятий, с которыми я борюсь:

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

Также документ Camel-Spring (ссылка выше) содержит следующий пример:

@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 ... но я не вижу откуда поступают эти сообщения (как они в первую очередь попадают в конечную точку)!

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

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

Заранее спасибо за любые толчки в правильном направлении!

Answer 1

Отличная практика для тщательного тестирования ваших маршрутов.Упомянутые вами ресурсы для тестирования Camel и 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 , чтобы найти удобные способы замены конечных точек в другом тесте (или производстве).) среда.DataSet - это удобный способ запустить или проверить серию сообщений.

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

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

Answer 2

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

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

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