JBoss Fuse — это мощная платформа распределенной интеграции со встроенными функциями для централизованного управления конфигурацией, обнаружения служб, управления версиями, шлюза API, балансировки нагрузки, отработки отказа и т. Д. Для развертываний микросервисов, ориентированных на интеграцию. JBoss Fuse 6.x построен поверх открытого проекта Fabric8 1.x. Этот блог является первой частью серии из двух частей, посвященной тестированию интеграции при создании интеграционных микросервисов поверх JBoss Fuse. 
Честно говоря, я приятно удивлен в эти дни, когда люди спрашивают о деталях стратегии тестирования для программного обеспечения / услуг, которые они пишут. Я полагал, что все согласны с тем, что тестирование важно, но на самом деле никто этого не делает. Я много работаю с клиентами, которые используют JBoss Fuse для написания своих интеграционных сервисов, и меня часто спрашивают, как лучше всего тестировать эти сервисы.
JBoss Fuse использует Apache Camel в качестве механизма маршрутизации и посредничества, и в итоге вы пишете основную логику интеграции с Camel. Для тестирования маршрутов Camel я настоятельно рекомендую использовать встроенную среду тестирования, с которой поставляется Camel. Более того, я не только рекомендую использовать встроенный тестовый набор, но и настоятельно рекомендую вам создавать большую часть ваших тестов с его помощью. Возможность запуска верблюда и связанных с ним тестов вне контейнера является очень важным отличием от других интеграционных решений, и тестирование должно в полной мере использовать этот факт.
Тем не менее, что, если у вас есть хорошее тестовое покрытие Camel, и теперь вы хотите сделать еще один шаг? Вы хотите развернуть ваши маршруты / приложения в контейнере JBoss Fuse и убедиться, что все было правильно подключено, что импорт / экспорт / метаданные OSGI были включены правильно, что сервисы подключены к сервису HTTP и т. Д. Это законные причины для развертывания в контейнер, но выполнение этого вручную подвержено ошибкам и медленно. Итак, какие есть варианты для автоматизации этого?
Я сталкивался с несколькими различными способами сделать это: используя Arquillian, который является интегрированной средой для тестирования контейнеров, изначально разработанной для сервера приложений JBoss / Wilfly / EAP. Есть несколько хороших модулей для тестирования интеграции ваших OSGI . Однако, как только вы попытаетесь провести больше интеграционного тестирования «черного ящика», Arquillian на данный момент недостаточно мощен для тестирования JBoss Fuse. Для этого я бы порекомендовал проект Pax Exam . Экзамен Pax существует уже довольно давно и используется для тестирования различных производных ServiceMix / Karaf, которые достаточно похожи на JBoss Fuse для тестирования.
Итак, чтобы не только помочь другим, желающим начать работу с Pax Exam для тестирования интеграции JBoss Fuse 6.x, я собрал учебник для начинающих … и более эгоистично … чтобы я мог записать эти заметки так, чтобы что я могу вернуться к ним; как я уже сделал это достаточно раз и забыл, что пришло время записать это.
itests
Обычно я создаю автоматизированные интеграционные тесты вместе с проектом, который собираюсь тестировать, в подмодуле под названием itests . Вы можете сделать то же самое или поместить свои интеграционные тесты в отдельный проект. Для этого руководства я встроил интеграционные тесты в пример проекта Rider Auto OSGI, который адаптирован из книги Клауса Ибсена и Джона Ансти « Верблюд в действии» . Не стесняйтесь просматривать этот проект, чтобы понять, что делают модули.
Для начала я настоятельно рекомендую вам просмотреть документацию Pax Exam, а затем заглянуть в файл с именем FuseTestSupport . В нем вы увидите метод, который вносит @Configuration в контейнер OSGI:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
// note, for this to work, you must download and put fuse in the location // specified by the maven coordinates here public static final String GROUP_ID = "org.jboss.fuse"; public static final String ARTIFACT_ID = "jboss-fuse-minimal"; public static final String VERSION = "6.1.0.redhat-379"; public static Option[] container() { return new Option[]{ karafDistributionConfiguration() .frameworkUrl(maven().groupId(GROUP_ID).artifactId(ARTIFACT_ID).version(VERSION).type("zip")) .karafVersion("2.3.0") .useDeployFolder(false) .name("JBoss Fuse") .unpackDirectory(new File("target/paxexam/unpack")), configureConsole().ignoreLocalConsole(), editConfigurationFilePut("etc/config.properties", "karaf.startup.message", "Loading Fabric from: ${karaf.home}"), editConfigurationFilePut("etc/org.ops4j.pax.web.cfg", "org.osgi.service.http.port", HTTP_PORT), editConfigurationFilePut("etc/org.apache.karaf.management.cfg", "rmiRegistryPort", RMI_REG_PORT), editConfigurationFilePut("etc/org.apache.karaf.management.cfg", "rmiServerPort", RMI_SERVER_PORT), editConfigurationFilePut("etc/users.properties", "admin", "admin,admin"), // this is the key... we can install features, bundles, etc. using these pax-exam options features(maven().groupId("org.fusesource.examples").artifactId("rider-auto-common").versionAsInProject().classifier("features").type("xml"), "rider-auto-osgi"), logLevel(LogLevelOption.LogLevel.INFO), // enable this if you want to keep the exploded directories of fuse after the tests are run// keepRuntimeFolder(), }; }; |
Обратите внимание, что мы используем реальный дистрибутив JBoss Fuse, а не какую-то взломанную версию. Чтобы это работало, вам нужно зайти на веб- сайт JBoss.org, скачать Fuse и установить его в свой репозиторий maven, соответствующий координатам, указанным в приведенном выше фрагменте кода, например:
|
1
|
~/.m2/repository/org/jboss/fuse/jboss-fuse-minimal/6.1.0.redhat-379/<put distro here> |
Теперь, когда тест запускается, он найдет предохранитель disto.
Вы также можете взглянуть на параметры конфигурации, включая редактирование некоторых из готовых параметров конфигурации, добавление функций, изменение уровня журнала и т. Д. Вы можете взглянуть на документацию KarafDistributionOption или CoreOptions, которые детализируют все Доступные Варианты.
Эта часть довольно проста. Вот пример простого теста, который построен поверх этой конфигурации :
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
|
@Inject@Filter("(camel.context.name=rider-auto-backend)")protected CamelContext camelContext;@Testpublic void testBootstrap() { assertNotNull(camelContext); ActiveMQComponent component = camelContext.getComponent("activemq", ActiveMQComponent.class); assertNotNull(component); String brokerUrl = ((ActiveMQConfiguration)component.getConfiguration()).getBrokerURL(); // make sure configuration was set up correctly assertEquals("tcp://localhost:61616", brokerUrl); // further validate that all of the camel contexts were installed correctly String contextList = executeCommand("camel:context-list"); assertTrue(contextList.contains("rider-auto-backend")); assertTrue(contextList.contains("rider-auto-file-poller")); assertTrue(contextList.contains("rider-auto-normalizer"));} |
Этот тест фактически внедряется в контейнер (подробности см. В документации по экзамену pax) и может получить доступ к внутренним частям контейнера (например, внедрение зависимостей) и выполнить некоторые утверждения на основе внутренних компонентов вашего развертывания.
тестирование черного ящика
Возможность запуска ваших автоматических интеграционных тестов таким образом, чтобы обеспечить полный доступ к вашему развертыванию и среде выполнения контейнера, — это прекрасно. Вы можете выполнить сложные тесты, чтобы убедиться, что все развернуто правильно, эта конфигурация была применена так, как вы думали, и что вы можете получить все ожидаемые сервисы. Но другой тип теста очень полезен: возможность развертывания ваших служб интеграции и удаленного (вне контейнера) использования функциональности, не зная подробностей. Например, взаимодействие с интерфейсами, предоставляемыми сервисом интеграции, такими как JMS, файловая система, конечные точки REST / SOAP и т. Д. Для доступа к этим интерфейсам можно использовать стандартные библиотеки. Но как вы представляете контейнер Fuse как черный ящик для этого типа тестирования? Ответ Pax Exam позволяет вам запускать ваш контейнер в «серверном» режиме . К сожалению, он представлен в виде API, который можно использовать для организации контейнера в режиме «сервер». Но лучший способ, если вы пользователь maven, — подключиться к жизненному циклу интеграционных тестов и позволить maven загрузиться и сломать сервер.
К счастью, проект Pax Exam также включает в себя плагин maven, который подключается к этапам тестирования интеграции жизненного цикла maven.
Например, включите это в ваш pom.xml :
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
|
<plugin> <groupId>org.ops4j.pax.exam</groupId> <artifactId>exam-maven-plugin</artifactId> <version>${pax.exam.version}</version> <configuration> <configClass>org.jboss.fuse.example.server.ServerConfiguration</configClass> </configuration> <executions> <execution> <goals> <goal>start-container</goal> <goal>stop-container</goal> </goals> </execution> </executions></plugin> |
Пожалуйста, взгляните на весь файл pom.xml, который показывает, как можно разбить вещи на профили Maven и подключить к отказоустойчивому плагину Maven для тестирования интеграции.
вспомогательные услуги
Пока Pax Exam проделывает большую работу для запуска наших автоматических интеграционных тестов с JBoss Fuse. Однако что, если мы хотим подключить дополнительные сервисы к загрузчику контейнера? Может быть, мы хотим инициировать экземпляр ActiveMQ до того, как появится контейнер (поскольку, возможно, у нас есть службы, которые нужно будет подключить к внешнему ActiveMQ… и мы можем затем использовать результаты сообщений в очередях / DLQ для подтверждения поведения и т. Д.) и убедитесь, что разорвали его в конце теста. Вы можете [расширить один из различных реакторов Pax Exam], чтобы сделать это:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
|
public class ActiveMQPerClass extends PerClass { protected BrokerService brokerService = null; @Override public StagedExamReactor create(List<TestContainer> containers, List<TestProbeBuilder> mProbes) { return new EagerSingleStagedReactor(containers, mProbes){ @Override public void beforeClass() { bootStrapActiveMQ(); super.beforeClass(); } @Override public void afterClass() { teardownActiveMQ(); super.afterClass(); } }; } |
И затем в вашем тесте, когда вы указываете стратегию реактора для использования, используйте наш собственный:
|
01
02
03
04
05
06
07
08
09
10
|
@RunWith(PaxExam.class)@ExamReactorStrategy(ActiveMQPerClass.class)public class BootstrapIT extends FuseTestSupport { @Inject @Filter("(camel.context.name=rider-auto-backend)") protected CamelContext camelContext; @Test public void testBootstrap() { ..... |
ткань предохранителя
Этот пост посвящен написанию интеграционных тестов для отдельных версий Fuse. Многое из той же механики будет использовано для создания интеграционных тестов против развертывания Fuse Fabric / Fabric8. Это будет во второй части этого поста. Будьте на связи! Также следите за мной в твиттере @christianposta для твитов о Fuse / Fabric8 / Microservices / DevOps и т. Д. И обновлений в новых сообщениях в блоге!
| Ссылка: | Интеграционное тестирование JBoss Fuse 6.x с Pax Exam, часть I от нашего партнера JCG Кристиана Поста в блоге |