Модульное тестирование доступно в Maven из коробки. Из-за этого очень часто его используют и для интеграционных тестов. Основным недостатком этого метода является то, что выполнение интеграционных тестов может занять гораздо больше времени, и потому что никто не любит долго ждать каждой сборки — тесты просто пропускаются с -Dmaven.test.skip=true
Чтобы выполнить интеграционные тесты с Maven, мы должны использовать плагин Maven Failsafe . Благодаря этому мы можем быстро запустить модульные тесты, вызвав mvn test
или выполнить интеграционные тесты с mvn verify
.
Интеграционные тесты должны выполняться в среде, максимально приближенной к производственной. Если ваше приложение представляет собой пакет WAR или EAR, вы можете использовать плагин Maven Cargo , чтобы указать Maven развернуть его на сервере приложений или в контейнере сервлетов и выполнить интеграционные тесты на развернутом приложении.
Конфигурация плагина Maven Failsafe
Для того, чтобы включить фазу тестирования интеграции, в pom.xml
необходимо добавить конфигурацию отказоустойчивого плагина.
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
|
... < build > < plugins > ... < plugin > < groupId >org.apache.maven.plugins</ groupId > < artifactId >maven-failsafe-plugin</ artifactId > < version >2.12</ version > < executions > < execution > < goals > < goal >integration-test</ goal > < goal >verify</ goal > </ goals > </ execution > </ executions > </ plugin > </ plugins > </ build > ... </ project > |
Теперь, когда вызывается mvn verify
все файлы, содержащие тесты, соответствуют src/test/java/**/*IT.java
будет выполняться на этапе интеграционных тестов.
Интеграционные тесты — это не что иное, как классы, использующие аннотации JUnit или TestNG, чтобы сообщить Maven, какой метод является тестом, и должен использовать тот же способ выполнения утверждений, что и в модульных тестах.
Конфигурация плагина Maven Cargo
Грузовой плагин поддерживает все основные серверы приложений на рынке . В моем примере я буду использовать установку Apache Tomcat 7 по умолчанию.
- Tomcat запускается на этапе предварительной интеграции
- кота останавливают на этапе постинтеграции
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
29
30
31
32
|
< plugin > < groupId >org.codehaus.cargo</ groupId > < artifactId >cargo-maven2-plugin</ artifactId > < version >1.2.0</ version > < configuration > < container > < containerId >tomcat7x</ containerId > < zipUrlInstaller > </ url > < downloadDir >${project.build.directory}/downloads</ downloadDir > < extractDir >${project.build.directory}/extracts</ extractDir > </ zipUrlInstaller > </ container > </ configuration > < executions > < execution > < id >start-tomcat</ id > < phase >pre-integration-test</ phase > < goals > < goal >start</ goal > </ goals > </ execution > < execution > < id >stop-tomcat</ id > < phase >post-integration-test</ phase > < goals > < goal >stop</ goal > </ goals > </ execution > </ executions > </ plugin > |
Это работает довольно хорошо. Теперь, когда вы впервые запускаете mvn verify
вы видите, что Tomcat загружается и запускается до запуска интеграционных тестов.
Пример интеграционного теста
Теперь мы можем наконец написать полезный интеграционный тест, который проверит, отправляет ли приложение правильный код ошибки в ответ.
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
|
import org.apache.http.HttpResponse; import org.apache.http.HttpStatus; import org.apache.http.client.HttpClient; import org.apache.http.client.methods.HttpGet; import org.apache.http.impl.client.DefaultHttpClient; import org.junit.Test; import java.io.IOException; import static org.fest.assertions.Assertions.assertThat; public class CheckApplicationDeployIT { @Test public void testIfAppIsUp() throws IOException { //given HttpClient client = new DefaultHttpClient(); HttpGet httpget = new HttpGet(URL); //when HttpResponse response = client.execute(httpget); //then assertThat(response.getStatusLine().getStatusCode()).isEqualTo(HttpStatus.SC_OK); } } |
Конечно, интеграционные тесты должны быть более сложными и фактически тестировать поведение. Прямо сейчас вы можете настроить Waitr, Selenium или любое другое решение, которое наилучшим образом соответствует вашим потребностям, и создать реальные интеграционные тесты.
Вывод
Всегда ли нужно тестировать развернутое приложение в интеграционных тестах? Это очень полезно, но не всегда. Если ваше приложение как-то зависит от IP-адреса пользователя, вы не сможете изменить его в разных запросах.
Но если ваше приложение является классическим веб-приложением с веб-интерфейсом HTML или REST — тогда это настоятельно рекомендуется.