Класс тестирования, расширяющий класс тестирования в модуле зависимостей
У меня есть тестовый класс в модуле, который расширяет другой тестовый класс в одном из его модулей зависимостей. Как импортировать код теста зависимостей в область проверки зависимого модуля?
Неграмотный, у меня есть два модуля, "модуль-один" - это зависимость от "module-two". SubTestCase
является подклассом TestCase
.
module-one
\src\test\java\com\example\TestCase.java
module-two
\src\test\java\com\example\SubTestCase.java
Но сборка не работает, потому что тестовый код "module-one" не импортируется в "module-two", а только основной код.
Ответы
Ответ 1
Обычно это решается путем создания и развертывания файлов modulename-test.jar в дополнение к обычному файлу modulename.jar. Вы развертываете их в репозитории, как обычные артефакты. Это не совсем безупречно, но подходит для артефактов кода.
Затем вы добавляете зависимости, связанные с тестированием, к тестовым банкам с другими модулями.
Вы также можете решить эту проблему, поставив артефакты с тестируемой областью в "главную" область действия в отдельный собственный модуль, а затем включите это в регулярную тестовую область в других модулях. Это решение не очень хорошо работает в многомодульной сборке, где каждый модуль экспортирует некоторые тестовые артефакты, поскольку вы в основном получаете 2N-модули.
Многие из нас фактически отказываются от обоих этих решений, когда понимаем, что количество классов довольно ограничено, и есть проблемы, связанные с обоими этими решениями. Мы просто помещаем их в соответствующий пакет в "основной" области. Я просто забываю, почему два первых решения - это боль.
Ответ 2
Вы можете развернуть тестовый код в качестве дополнительного артефакта, используя maven-jar-plugin test-jar goal. Он будет прикреплен к проекту и развернут с помощью тестов классификатора.
<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>
Ответ 3
Относительно ответа богатого продавца:
Использование <classifier>tests</classifier>
отсутствует в руководстве пользователя .
Я использую maven 2.2.1 и maven-jar-plugin 2.2, и это необходимо для
switch <type>test-jar</type>
вместо <classifier>tests</classifier>
.
Обратите внимание, что флаги тестов не являются транзитивными, поэтому вам может потребоваться их добавить явно.
<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 см. Ссылку выше говорит
Обратите внимание, что предыдущие версии этого руководства предложили использовать < классификатоp > тесты </classifier> вместо <type> test-jar </type> . Пока это работает в некоторых случаях, оно не работает должным образом во время сборки реактора JAR-модуля и любого потребителя если вызывается этап жизненного цикла до установки. В таком сценарии, Maven не разрешит тестовый JAR с выхода реактора но из локального/удаленного репозитория. По-видимому, JAR из репозитории могут быть устаревшими или полностью отсутствовать, что приводит к (см. MNG-2045).