Для Deployit , продукта автоматического развертывания XebiaLabs для приложений Java EE, мы всегда строим и модифицируем интеграцию с системами промежуточного программного обеспечения, такими как IBM WebSphere , Oracle WebLogic и сервер приложений JBoss . Эти интеграции достаточно малы, чтобы их можно было изменить, чтобы получить много разных сценариев развертывания. Типичным шагом , как мы называем эти интеграции , будет «Создать источник данных WebSphere» или «Перезапустить WebLogic Server». Так как же проверить этот код?
Мы добились определенного успеха, используя Fitnesse и VMWare для проведения интеграционных тестов в наших сценариях развертывания. Но было несколько проблем с этим apporach:
- Таким образом, мы могли протестировать только полные сценарии развертывания. Если мы хотели протестировать только один шаг, нам нужно было создать сценарий развертывания, который использовал бы этот шаг, чтобы иметь возможность протестировать его.
- Поскольку Fitnesse не предоставляет никакой обратной связи во время выполнения теста и выполнение шагов, не говоря уже о сценариях развертывания, иногда может занять некоторое время, было мало отзывов о ходе выполнения.
- Хотя можно отлаживать прибор Fitnesse с помощью Eclipse, этот процесс не очень удобен при отладке технического компонента, такого как этот шаг.
- Чтобы убедиться, что сценарий развертывания успешно выполнен, нам пришлось часто расширять наше приспособление Fitnesse. И хотя отладка тестируемого кода в Fitnesse достаточно сложна, отладка Fixture еще сложнее!
Очевидно, что нам нужен другой подход, если мы хотим легко разрабатывать новые шаги.
От фитнеса до юнита
Прежде всего мы решили отказаться от Fitnesse в качестве основы тестирования. Хотя это может быть очень полезно, чтобы инструмент проводил приемочное тестирование пользователей и позволял конечным пользователям писать (или, по крайней мере, понимать) тесты, техническая природа нашего продукта уже гарантировала, что у нас не будет тестов для нетехнических конечных пользователей. Вкупе с проблемами, которые нам давала Фитнесс, это было достаточной причиной, чтобы взглянуть на вездесущий JUnit. Ясно, что мы не пишем модульные тесты, но инфраструктура JUnit пригодна для любого вида автоматического тестирования кода. Чтобы отличить этот тест интеграции от обычных тестов JUnit, мы выбираем имена классов, заканчивающиеся на Itest. Это гарантировало, что обычная сборка Maven не выполнит их; по умолчанию плагин Surefire выполняет только те тесты, имя класса которых заканчивается на Test (с большой буквы T).
Базовый подход к тестированию
Базовый подход, используемый в наших тестах, выглядит следующим образом:
- Утвердите, что конфигурация Java EE (например, источник данных или развернутое приложение) не существует.
- Выполните шаг, который создает конфигурацию Java EE.
- Утверждают , что конфигурация Java EE делает существует.
- Утвердите, что свойства конфигурации Java EE (например, URL источника данных) имеют ожидаемые значения.
- Выполните шаг, который уничтожает конфигурацию Java EE.
- Утверждают, что конфигурация Java EE больше не существует.
Можно утверждать, что этот тест на самом деле тестирует два фрагмента кода: шаг создания и шаг уничтожения. Но тест на правильное уничтожение ресурса должен сначала его настроить. И тест, создающий ресурс, должен очищаться после него, чтобы следующий тест работал правильно. Это означает, что тесты зависят от правильной очистки предыдущего теста, но в следующем блоге я покажу, как вы можете использовать VMWare для решения этой проблемы.
Утверждая, что ресурсы созданы правильно
Самым сложным в этом подходе является утверждение о том, что конфигурация Java EE существует (или не существует) и имеет ожидаемые свойства. Для этого мы должны проверить конфигурацию. К сожалению, для каждого из трех упомянутых серверов приложений требуется свой метод.
Проверка конфигурации IBM WebSphere
Для проверки конфигурации IBM WebSphere мы выполняем приведенный ниже скрипт wsadmin, а затем анализируем выходные данные, чтобы построить Map <String, String> свойств объекта, на который указывает путь содержания . Если скрипт завершается с ненулевым кодом выхода, мы знаем, что объект не существует в конфигурации.
# Read command line arguments
containmentpath = sys.argv.pop(0)
# Get object ID by containment path
objectid = AdminConfig.getid(containmentpath)
if objectid == "":
print "Object with containment path " + containmentpath + " not found"
sys.exit(1)
# Print object properties
print AdminConfig.show(objectid)
Проверка конфигурации Oracle WebLogic
Oracle WebLogic имеет концепцию, очень похожую на путь локализации IBM WebSphere, но нет конкретного названия для этой концепции. Таким образом, в сценарии WLST, который вы видите ниже, мы также называем его путь сдерживания. Помимо того, что WLST требует tou для подключения к серверу администрирования внутри сценария, в то время как wsadmin выполняет подключение для вас на основе параметров командной строки, сценарий для WebLogic выполняет ту же работу, что и сценарий для WebSphere:
# Read command line arguments
scriptname = sys.argv.pop(0)
username = sys.argv.pop(0)
password = sys.argv.pop(0)
url = sys.argv.pop(0)
containmentpath = sys.argv.pop(0)
# Connect to the WebLogic admin server
connect(username, password, url)
# List the properties of the object
ls(containmentpath)
# Disconnect and exit
disconnect()
exit()
Проверка конфигурации JBoss
JBoss не имеет основанного на Python интерфейса административного скриптинга, но у него есть twiddle . Команда запроса Twiddle позволяет нам проверять наличие MBean, а команда get — извлекать свойство MBean. Нет команды для получения всех свойств MBean, но twiddle выполняется так быстро, что не проблема выполнить его несколько раз.
Продолжение следует…
Все это позволяет нам убедиться, что конфигурация была создана правильно, но все же не говорит нам, может ли приложение действительно использовать эту конфигурацию. Я расскажу о том, как это сделать, в следующей части (но я обещаю, что я не буду делать серию, пока серия шаблонов реализации JPA 
). И я также объясню, как Maven и VMWare вписываются во все это.