测试类在依赖模块中扩展测试类

时间:2008-12-11 16:16:59

标签: java maven-2

我在一个模块中有一个测试类,它在一个依赖模块中扩展了另一个测试类。如何将依赖项的测试代码导入依赖模块的测试范围?

为了文盲,我有两个模块,“模块一”是“模块二”的依赖。 SubTestCaseTestCase的子类。

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

但是构建失败了,因为“module-one”的测试代码没有导入“module-two”,只是主代码。

3 个答案:

答案 0 :(得分:32)

您可以使用maven-jar-plugin's 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>

然后,其他项目可以通过在依赖项中声明测试分类器来引用测试jar。

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

答案 1 :(得分:9)

关于Rich Seller的回答: <classifier>tests</classifier>的使用已过时,请参阅user’s guide

我正在使用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>

更新以下Mike Sokolov评论:
2014-03-28更新了maven 3的用户公会,请参阅上面的链接说明

  

请注意,本指南以前的版本建议使用   &LT;分类&GT;试验&LT; /分类&GT;而不是&lt; type&gt; test-jar&lt; / type&gt;。   虽然目前适用于某些情况,但在测试JAR模块和任何消费者的反应堆构建期间,它无法正常工作   如果调用安装之前的生命周期阶段。在这种情况下,   Maven不会从反应堆的输出中解析测试JAR   但是从本地/远程存储库构建。显然,JAR来自   存储库可能已过时或完全丢失,导致存储库   构建失败(参见MNG-2045)。

答案 2 :(得分:5)

通常,除了常规modulename.jar文件之外,还可以通过构建和部署modulename-test.jar文件来解决此问题。您可以像常规工件一样将这些部署到repos。这并非完全无瑕疵,但对于代码工件来说效果不错。

然后,您将测试范围的依赖项添加到test-jar到其他模块。

您也可以通过将测试范围工件放在“main”范围内的单独模块中来解决此问题,然后将其包含在其他模块的常规测试范围中。此解决方案在多模块构建中不能很好地工作,其中每个模块都会导出一些测试工件,因为您基本上可以获得2N模块。

当我们意识到类的数量相当有限并且存在与这两种解决方案相关的问题时,我们很多人实际上都放弃了这两种解决方案。我们只是将它们放在“主要”范围内的适当命名的包中。我只是忘记了为什么这两个第一个解决方案都很痛苦。