В прошлом году, перед рождественскими каникулами 
, я описал, как мы проводим интеграционное тестирование промежуточного программного обеспечения в XebiaLabs, и описал способ развертывания тестовых сервлетов, помещая их в файлы WAR и EAR, которые создаются на лету . Осталось объяснить только одно; Как интегрировать эти тесты в непрерывную сборку с использованием Maven и VMware?
Выполнение интеграционных тестов промежуточного программного обеспечения
Итак, давайте начнем с конфигурации Maven. Как я упоминал в первом блоге этой серии, интеграционные тесты узнаваемы по тому, что имена классов заканчиваются на Itest. Это означает, что они не будут включены в стандартную конфигурацию плагина Maven Surefire . И это удачно, потому что мы не всегда хотим запускать эти тесты. Во-первых, они требуют очень специфической настройки теста (конфигурации сервера приложений должны находиться в ожидаемом состоянии, см. Ниже), а во-вторых, они могут занять много времени, что может помешать быстрому возврату, который мы хотим от сборок коммитов в наша система непрерывной интеграции.
Но когда мы действительно хотим запустить интеграционные тесты промежуточного слоя, мы можем настроить плагин Maven Surefire с Maven профиль сборки , как так:
<profiles>
<profile>
<id>itest</id>
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<includes>
<include>**/Test*.java</include>
<include>**/*Test.java</include>
<include>**/*TestCase.java</include>
<include>**/*Itest.java</include>
</includes>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Чтобы запустить тесты интеграции промежуточного программного обеспечения в дополнение к обычным тестам, мы можем сказать Maven использовать этот профиль с флагом -P:
$ mvn -Pitest test
Если мы хотим, чтобы этот профиль выполнял только интеграционные тесты промежуточного программного обеспечения, нам нужно пропустить строки, содержащие стандартные имена классов (Test * .java, * Test.java и * TestCase.java).
Определение ожидаемого состояния для целевого промежуточного программного обеспечения
При выполнении интеграционных тестов промежуточного программного обеспечения большая проблема заключается в том, чтобы гарантировать, что промежуточное ПО, с которым мы тестируем, находится в правильном состоянии. Например, тест может ожидать, что кластер сервера приложений будет запущен, но на нем не будет развернуто приложение. В обычном тесте мы можем установить тестовое устройство в методе, помеченном @Before , но в этом случае это может быть не так просто. Настройка промежуточного программного обеспечения для работы в ожидаемом состоянии была бы интеграцией сама по себе!
Первый подход к решению этой проблемы заключается в написании всех интеграционных тестов промежуточного программного обеспечения таким образом, чтобы они отменяли любые внесенные изменения. Например, тест, который создает источник данных, также удаляет его. Таким образом, мы объединяем тест для этапа создания с тестом для этапа уничтожения. Недостатком здесь является то, что эти два этапа больше нельзя тестировать независимо, но преимущество заключается в том, что комбинированный тест выполняется быстрее. Чтобы этот подход был успешным, все тесты, использующие одно и то же целевое промежуточное ПО, должны согласовать общее ожидаемое состояние. Мы настраиваем целевое промежуточное ПО в этом состоянии один раз, и все тесты возвращают промежуточное ПО в это состояние после завершения. С такой установкой мы можем быстро запустить один или несколько интеграционных тестов, либо в интерактивном режиме из IDE, такой как Eclipse, либо из Maven.
Но есть одна проблема с этим. Что если тест не пройден? В этом случае промежуточное программное обеспечение может не оставаться в правильном состоянии. Можно утверждать, что шаги, необходимые для возврата промежуточного программного обеспечения, должны быть помещены в метод @After, но они все равно могут потерпеть неудачу. Что еще более важно, эти шаги также являются частью теста, поэтому они на самом деле не принадлежат!
Возврат целевого промежуточного программного обеспечения в ожидаемое состояние с помощью VMware
Вот тут и вступает VMware. Установив промежуточное ПО в гипервизоре, таком как VMware, мы можем сделать снимок, когда промежуточное ПО находится в ожидаемом состоянии. Затем мы можем вернуться в это состояние перед выполнением одного теста или набора тестов. Самое простое — вручную вернуться из консоли администрирования гипервизора перед запуском тестов. Но мы также можем автоматически возвращать изображения, чтобы мы могли интегрировать эти тесты в наши сборки непрерывной интеграции .
Образы, которые мы используем для наших интеграционных тестов промежуточного программного обеспечения, работают на VMware vSphere 4, и мы обнаружили, что vSphere SDK для Perl и, в частности, предоставленный пример сценария vmrun.pl, является наиболее простым способом взаимодействия с VMware vSphere. Например, это скрипт, который мы используем для возврата нашего изображения JBoss:
IMAGE_NAME="[datastore1] jboss-42/CentOS 5.3, JBoss 4.2.3-GA.vmx"
SNAPSHOT_NAME="Ready for itest"
SETTLE_TIME=60
VMRUN=/usr/lib/vmware-vix/lib/api/vix-perl/samples/vmrun.pl
echo "Reverting VMWare image $IMAGE_NAME to snapshot $SNAPSHOT_NAME"
$VMRUN -host $VMWARE_HOST -username $VMWARE_USERNAME -password $VMWARE_PASSWORD \
revertToSnapshot "$IMAGE_NAME" "$SNAPSHOT_NAME"
echo "Waiting $SETTLE_TIME seconds for things to settle"
sleep $SETTLE_TIME
Нам нужно предоставить правильные значения для переменных среды VMWARE_HOST, VMWARE_USERNAME и VMWARE_PASSWORD при запуске этого скрипта. После того, как изображение было возвращено, мы ждем в течение 60 секунд, чтобы позволить изображению обосноваться. Количество секунд, необходимое здесь, трудно точно определить, но это значение хорошо работает для нас.
Чтобы Maven запустил этот сценарий до выполнения интеграционных тестов, но только при выборе определенного профиля, мы добавили эту конфигурацию в POM:
<profiles>
<profile>
<id>revert-vmware-images</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<!-- We really want this to execute right before the test phase. -->
<!-- This is the best we can do. -->
<phase>process-test-resources</phase>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>/bin/sh</executable>
<commandlineArgs>src/test/scripts/revert-vmware-images.sh</commandlineArgs>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Положить его вместе
С помощью двух профилей, представленных в этом блоге, мы сообщаем Maven вернуть образы VMware и выполнить все тесты интеграции промежуточного программного обеспечения, выполнив следующую команду:
$ mvn -Prevert-vmware-images -Pitest clean test
Мы настроили нашу систему непрерывной интеграции для запуска этой команды один раз в день в качестве вторичной сборки и настроили ее с правильными значениями для переменных среды VMWARE_HOST, VMWARE_USERNAME и VMWARE_PASSWORD. Таким образом, тесты интеграции промежуточного программного обеспечения не замедляют стандартную сборку коммита (в нашем случае это занимает около 90 минут!). В качестве дополнительного преимущества мы знаем, когда образы VMware будут использоваться тестами, чтобы мы могли использовать их для ручных экспериментов в другое время.
Вывод
В этом и первых двух блогах этой серии я объяснил, как мы используем JUnit , Maven и VMware для написания повторяемых, управляемых тестов интеграции промежуточного программного обеспечения. Эти тесты помогли нам обрести уверенность в стабильности интеграции промежуточного ПО Deployit . И поскольку этот код поддержки тестирования является частью API плагина Deployit, разработчики плагина Deployit могут использовать его для получения такой же уверенности в своем собственном коде!