Интеграционные тесты с Maven, JUnit и Spring

[WFrag]

А почему не через maven-failsafe-plugin?

[javax]

Если я правильно понимаю, то с ним тесты всё равно будут бежат, ь если я делаю «deploy», так? Ведь фаза integration-test перед деплоем.

А мне хотелось и деплой без них запускать

[WFrag]

С failsafe plugin можно так же вынести в отдельный профиль. Просто failsafe предлагает более аккуратное разделение unit и не-unit тестов, без рукопашных фильтров.

[javax]

Про то, что можно вынести в отдельный профиль, я не знал, посмотрю — спасибо!

[sody]

<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>

[dmmm]

failsafe замечательный плагин, но в данном случае если его использовать — это увеличит время обратной связи от тестов, так как они будут запускаться в фазе integration-test. Реальной необходимости в этом нет, так как этот тест можно запустить и в фазе test. В случае если тест упадет мы узнаем об этом через большее количество времени.
Реальная необходимость запускать тесты в фазе integration-test имеется только в случае если тесту необходим результат билда: упакованный jar, war или еще какой-нибудь файл.
По сути это некое несоответствие названия фазы integration-test её задаче, интеграционные тесты можно запускать и из обычной фазы test, если они не требуют результат сборки.

[jbaruch]

Да, integration tests в maven-е — это вечная тема.
Мой любимый use-case для демонстрации превосходства Gradle. Например — prezi.com/8rzz3lcsjbg7/gradle-a-better-way-to-build/ если перемотать на bed time story, аккурат про integration tests.

[javax]

Кто о чём, а вшивый о бане :)

[jbaruch]

«with a passion», чо

[Slider_X]

Удобнее выделить под интегрейшн тесты отдельный каталог (пусть будет integration) на уровне main и test. И там поддерживать стандартную иерархию java, resources. Таким образом тесты будут лежать в том же пакете, что и тестируемые классы, что добавит гораздо большую гибкостью. Плюс, они (код, необоходимые ресурсы) будут лежать действительно отдельно от юнит тестов.
А при описанном вами подходе сложность разработки и поддержки большого проекта будет расти экспоненциально.

[WFrag]

Да не то, чтобы экспоненциально, но путаница из-за таких «магических» пакетов возникнуть может. Особенно через пару лет, когда разработчики, занимающиеся билдом и тестами, пару раз сменятся.

[javax]

Отдельный каталог хорошая идея, не подумал. А IDEA его там сама распознает как соурс?

[Slider_X]

В любой IDE можно указать какие папки считать исходниками. К примеру, в идее вообще можно указать какие папки считать тестами (про другие IDE не знаю). Но придется добавлять в мавеновскую конфигурацию эти каталоги. У нас примерно так организована структура проекта, и всё работает.

[javax]

Ясно, что можно указать в идее и можно в мавене, вопрос будут ли эти директории опознаваться идеей как соурсные при автосинхронизации с pom.xml

[Slider_X]

Что значит опознаваться? Как в проекте укажите, так и будет опознаваться. Как я уже написал выше, у нас в проекте всё прекрасно работает.