Комментарии 15
А почему не через maven-failsafe-plugin?
Если я правильно понимаю, то с ним тесты всё равно будут бежат, ь если я делаю «deploy», так? Ведь фаза integration-test перед деплоем.
А мне хотелось и деплой без них запускать
А мне хотелось и деплой без них запускать
С failsafe plugin можно так же вынести в отдельный профиль. Просто failsafe предлагает более аккуратное разделение unit и не-unit тестов, без рукопашных фильтров.
Про то, что можно вынести в отдельный профиль, я не знал, посмотрю — спасибо!
<profile>
<id>it</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<executions>
<execution>
<id>integration-test</id>
<goals>
<goal>integration-test</goal>
</goals>
</execution>
<execution>
<id>verify</id>
<goals>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-invoker-plugin</artifactId>
<executions>
<execution>
<id>integration-test</id>
<goals>
<goal>install</goal>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
failsafe замечательный плагин, но в данном случае если его использовать — это увеличит время обратной связи от тестов, так как они будут запускаться в фазе integration-test. Реальной необходимости в этом нет, так как этот тест можно запустить и в фазе test. В случае если тест упадет мы узнаем об этом через большее количество времени.
Реальная необходимость запускать тесты в фазе integration-test имеется только в случае если тесту необходим результат билда: упакованный jar, war или еще какой-нибудь файл.
По сути это некое несоответствие названия фазы integration-test её задаче, интеграционные тесты можно запускать и из обычной фазы test, если они не требуют результат сборки.
Реальная необходимость запускать тесты в фазе integration-test имеется только в случае если тесту необходим результат билда: упакованный jar, war или еще какой-нибудь файл.
По сути это некое несоответствие названия фазы integration-test её задаче, интеграционные тесты можно запускать и из обычной фазы test, если они не требуют результат сборки.
Да, integration tests в maven-е — это вечная тема.
Мой любимый use-case для демонстрации превосходства Gradle. Например — prezi.com/8rzz3lcsjbg7/gradle-a-better-way-to-build/ если перемотать на bed time story, аккурат про integration tests.
Мой любимый use-case для демонстрации превосходства Gradle. Например — prezi.com/8rzz3lcsjbg7/gradle-a-better-way-to-build/ если перемотать на bed time story, аккурат про integration tests.
Удобнее выделить под интегрейшн тесты отдельный каталог (пусть будет integration) на уровне main и test. И там поддерживать стандартную иерархию java, resources. Таким образом тесты будут лежать в том же пакете, что и тестируемые классы, что добавит гораздо большую гибкостью. Плюс, они (код, необоходимые ресурсы) будут лежать действительно отдельно от юнит тестов.
А при описанном вами подходе сложность разработки и поддержки большого проекта будет расти экспоненциально.
А при описанном вами подходе сложность разработки и поддержки большого проекта будет расти экспоненциально.
Да не то, чтобы экспоненциально, но путаница из-за таких «магических» пакетов возникнуть может. Особенно через пару лет, когда разработчики, занимающиеся билдом и тестами, пару раз сменятся.
Отдельный каталог хорошая идея, не подумал. А IDEA его там сама распознает как соурс?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интеграционные тесты с Maven, JUnit и Spring