Comments 15
Если я правильно понимаю, то с ним тесты всё равно будут бежат, ь если я делаю «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) на уровне main и test. И там поддерживать стандартную иерархию java, resources. Таким образом тесты будут лежать в том же пакете, что и тестируемые классы, что добавит гораздо большую гибкостью. Плюс, они (код, необоходимые ресурсы) будут лежать действительно отдельно от юнит тестов.
А при описанном вами подходе сложность разработки и поддержки большого проекта будет расти экспоненциально.
Да не то, чтобы экспоненциально, но путаница из-за таких «магических» пакетов возникнуть может. Особенно через пару лет, когда разработчики, занимающиеся билдом и тестами, пару раз сменятся.
Отдельный каталог хорошая идея, не подумал. А IDEA его там сама распознает как соурс?
В любой IDE можно указать какие папки считать исходниками. К примеру, в идее вообще можно указать какие папки считать тестами (про другие IDE не знаю). Но придется добавлять в мавеновскую конфигурацию эти каталоги. У нас примерно так организована структура проекта, и всё работает.
Ясно, что можно указать в идее и можно в мавене, вопрос будут ли эти директории опознаваться идеей как соурсные при автосинхронизации с pom.xml
Что значит опознаваться? Как в проекте укажите, так и будет опознаваться. Как я уже написал выше, у нас в проекте всё прекрасно работает.
Only those users with full accounts are able to leave comments. Log in, please.