Тестовый класс, расширяющий тестовый класс в модуле зависимостей

Question

У меня есть тестовый класс в модуле, который расширяет другой тестовый класс в одном из его модулей зависимостей. Как я могу импортировать тестовый код зависимости в область тестирования зависимого модуля?

Для неграмотных у меня есть два модуля, модуль-один является зависимостью от модуля-два. SubTestCase является подклассом TestCase.

module-one
          \src\test\java\com\example\TestCase.java
module-two
          \src\test\java\com\example\SubTestCase.java

Но сборка не удалась, потому что тестовый код "module-one" не импортируется в "module-two", а только в основной код.

Answer 1

Вы можете развернуть тестовый код в качестве дополнительного артефакта с помощью цели maven-jar-plugin's test-jar . Он будет прикреплен к проекту и развернут с помощью тестов классификатора.

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <executions>
      <execution>
        <phase>package</phase>
        <goals>
          <goal>test-jar</goal>
        </goals>
      </execution>
    </executions>
  </plugin>

Другие проекты могут затем ссылаться на тестовую флягу, объявляя классификатор тестов в зависимости.

<dependency>
  <groupId>name.seller.rich</groupId>
  <artifactId>foo</artifactId>
  <version>1.0.0</version>
  <classifier>tests</classifier>
  <scope>test</scope>
</dependency>

Answer 2

Относительно ответа богатого продавца: Использование <classifier>tests</classifier> устарело, см. Руководство пользователя .

Я использую maven 2.2.1 и maven-jar-plugin 2.2, и требуется переключатель <type>test-jar</type> вместо <classifier>tests</classifier>.

Обратите внимание, что тесты jar не являются транзитивными, поэтому вам может потребоваться добавить их явно.

<project>
    ...
    <dependencies>
        <dependency>
            <groupId>name.seller.rich</groupId>
            <artifactId>foo</artifactId>
            <version>1.0.0</version>
            <type>test-jar</type>
            <scope>test</scope>
         </dependency>
    </dependencies>
     ...
</project>

Обновление после комментария Майка Соколова:
Гильдия пользователя для maven 3 обновлена ​​2014-03-28, см. Ссылку выше, например,

Обратите внимание, что в предыдущих выпусках этого руководства предлагалось использовать тесты вместо тест-банка . Хотя в настоящее время это работает в некоторых случаях, оно не работает должным образом во время сборки реактора тестового модуля JAR и любого потребителя если вызвана фаза жизненного цикла до установки. При таком сценарии Maven не разрешит тестовый JAR с выхода реактора сборка но из локального / удаленного репозитория. Судя по всему, JAR из хранилища могут быть устаревшими или полностью отсутствующими, что приведет к сбой сборки (ср. MNG-2045).

Answer 3

Обычно это решается созданием и развертыванием файлов modulename-test.jar в дополнение к обычному файлу modulename.jar. Вы развертываете их в репозитории как обычные артефакты. Это не совсем безупречно, но работает достойно для артефактов кода.

Затем вы добавили бы тестовые зависимости в jar-тестах для других модулей.

Вы также можете решить эту проблему, поместив артефакты тестовой области в «основную» область видимости в отдельный модуль, а затем включив их в обычную область видимости в другие модули. Это решение не очень хорошо работает в многомодульной сборке, где каждый модуль экспортирует некоторые тестовые артефакты, поскольку вы в основном получаете модули 2N.

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