Тест завершения интеграции для нескольких загрузочных приложений spring под Maven

Каков рекомендуемый способ тестирования сквозной интеграции для нескольких приложений загрузки Spring на фазе проверки сборки Maven?

В принципе, у меня есть мультимодульный проект Maven, в котором несколько модулей являются отдельными загрузочными приложениями spring. Эти отдельные приложения имеют собственную конфигурацию для источников данных, потоки интеграции с очередями JMS и т.д. Например, приложение A будет опроса базы данных для события, а когда это произойдет, оно создает файл данных JSON и помещает сообщение в очереди JMS. Приложение B опросит очередь JMS, так что берет сообщение, читает файл, выполняет некоторую обработку с использованием другой базы данных и помещает сообщение в другую очередь. Приложение C затем подберет это сообщение и т.д. И т.д.

Я установил интеграционные тесты для отдельных приложений; они запускаются под защищенным плагином Maven. Тем не менее, я хотел бы интегрировать тестирование всей системы, в конце, под Maven. Я создал отдельный модуль в проекте, посвященном этой задаче, и хотел бы, чтобы эта фаза сборки этого модуля провела окончательное тестирование с использованием других зависимых модулей.

Есть ли лучший способ сделать это? Я вижу 3 возможных способа:

Загрузите каждую конфигурацию приложения в один и тот же контекст приложения. Однако из-за множества источников данных и т.д. Это создает конфликты, поэтому все эти источники данных должны быть настроены вручную, чтобы обеспечить сквозное тестирование интеграции - так что это кажется мне неправильным.
Запустите каждое приложение как отдельный процесс - как правильно правильно отслеживать их и убедиться, что они закрываются, если сборка тестового модуля останавливается/вылетает/etc?
Есть ли способ легко загрузить отдельные загрузочные приложения spring, каждый со своим контекстом конфигурации, в том же процессе? Казалось бы, это самый разумный вариант. Существуют ли какие-либо соображения в отношении плагина сборки/отказоустойчивости Maven?

Ответ 1

Очень хороший вопрос! Я сам был бы заинтересован, что ответят другие люди. Я поделюсь своим мнением.

В моем понимании, прежде всего, вы должны знать, что именно вы хотите проверить. Интеграционные тесты должны работать с приложением, по крайней мере, с его частью, и убедиться, что компонент, который вы разработали, работает правильно в полуреальном окружении. Похоже, вы уже это сделали.

Теперь о системных тестах (я намеренно различаю интеграцию и системные тесты). Они должны "имитировать" парней QA:) Итак, они рассматривают систему как черный ящик. Они не могут вызывать любые внутренние API-интерфейсы и запускать реальные потоки. Итоговые тесты ИМО попадают в эту категорию.

В этом случае вы хотели бы проверить их на систему, развернутую как в процессе производства, с помощью classpath, как в процессе производства.

Поэтому я действительно не верю в вариант 1, как и вы.

Что касается варианта 3, я не уверен, что это хорошее решение. Даже если вы запускаете свои материалы в разных контекстах приложений (я не знаю, сколько загрузок Spring, поэтому я не могу технически комментировать его), в моем понимании они будут использовать один и тот же путь к классам во время выполнения, поэтому, возможно, вы находитесь в риск столкнуться между вашими третьими сторонами (хотя я знаю, что boot Spring определяет множество версий банок самостоятельно, вы знаете, что я имею в виду), особенно когда вы обновляете только один модуль и, возможно, изменяете зависимости. Таким образом, вы не знаете, что именно работает в памяти, когда вы запускаете этот подход.

Итак, для тестов end-to-end я бы выбрал вариант 2. Что касается синхронизации, вероятно, вариант будет реализовывать некоторую логику на уровне приложения в сочетании с отслеживанием состояния процесса на уровне операционной системы. Еще один момент, который я хотел бы прокомментировать, - это то, что сквозные тесты в целом по-прежнему являются функциональным тестированием (они проверяют функциональное поведение системы), поэтому в общем случае вы не должны проверять системные сбои там в каждом тесте. Если вы проверите системный сбой для каждого потока, эти тесты будут слишком медленными. Конечно, вы можете поддерживать один относительно небольшой набор тестов, чтобы проверять угловые случаи как таковые.

Надеюсь, что это поможет

Ответ 2

Просто для продолжения и скажите, что я сделал (что продолжает работать хорошо):

В моем тестовом модуле были созданы следующие профили Maven: "default" для пропуска тестов по умолчанию (мы используем jgitflow, поэтому хотим только -t-end тесты выполняются при явном запросе), "standalone-e2e" для сквозных тестов, не требующих внешних ресурсов, таких как базы данных (предназначенные для разработчиков, желающих выполнить полный сквозной тест), и "интегрированные -e2e" для сквозных тестов с использованием реальных баз данных и т.д. (которые могут запускаться как часть CI). Профили Spring (активированные соответствующим профилем Maven) управляют конфигурацией отдельных компонентов.
Для автономных e2e соответствующие плагины, такие как activeemq-maven-plugin, hsqldb-maven-plugin и т.д. запускают (и позже завершают) ресурсы как часть сквозного теста, работающего на портах, зарезервированных с помощью build-helper-maven-plugin. process-exec-maven-plugin используется для запуска всех компонентов, подлежащих тестированию на этапе предварительной интеграции (как стандарт Spring Загрузочные приложения), и он автоматически позаботится о том, чтобы закрыть их на этапе после интеграции. Конфигурация Spring и конкретные зависимости Maven зависят от других ресурсов, таких как поддельный FTP-сервер. После запуска всех ресурсов и компонентов сам тестовый код заполняет базу данных и файловую систему по необходимости и запускает потоки (и ждет соответствующих ответов и т.д.) С помощью JMS.
Профиль Integrated-e2e почти идентичен, но использует "реальные" внешние ресурсы (в нашем случае, очереди ASQ Amazon, базу данных MySQL и т.д.), настроенные в связанных свойствах Spring.
Все файлы, необходимые для тестов (например, файлы данных, файлы HSQLDB, файлы журналов и т.д.), создаются в каталоге "target", поэтому легко проверить эту область, чтобы узнать, что произошло во время теста, а также разрешить "mvn clean" очистить все.

Я надеюсь, что это полезно - было, конечно, полезно узнать, что мне нужно было сделать, плагин Maven существовал, чтобы позаботиться об этом!