Test class extending test class in dependency module

Question

I've got a test class in a module that extends another test class in one of its dependency modules. How can I import the dependency's test code into the test scope of the dependent module?

To illiterate, I've got two modules, "module-one" being a dependency of "module-two". SubTestCase is a subclass of TestCase.

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

But the build is failing because the test code of "module-one" is not being imported into "module-two", just the main code.

Rich Seller · Accepted Answer · 2009-07-30 13:53:00Z

You can deploy the test code as an additional artifact by using the maven-jar-plugin's test-jar goal. It will be attached to the project and deployed with the classifier tests.

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

Other projects can then reference the test jar by declaring the tests classifier in the dependency.

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

Worked brilliantly for me, Rich, thank you! This should be the accepted answer. krosenvolds answer is a fair discussion but misses this very apt use of the maven-jar-plugin feature.
Ok, quick test says no. Any ideas how to include test-sources and their dependencies?

Haim Raman · Accepted Answer · 2014-03-29 04:14:33Z

Regarding Rich Seller's answer: The use of <classifier>tests</classifier> is out dated see the user’s guide.

I am using maven 2.2.1 and maven-jar-plugin 2.2 and it required to switch <type>test-jar</type> instead of <classifier>tests</classifier>.

Note that tests jar are not transitive and so you may need to add them explicitly.

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

Update following Mike Sokolov comment:
The user’s guild for maven 3 updated on 2014-03-28 see link above say’s

Note that previous editions of this guide suggested to use <classifier>tests</classifier> instead of <type>test-jar</type>. While this currently works for some cases, it does not properly work during a reactor build of the test JAR module and any consumer if a lifecycle phase prior to install is invoked. In such a scenario, Maven will not resolve the test JAR from the output of the reactor build but from the local/remote repository. Apparently, the JAR from the repositories could be outdated or completely missing, causing a build failure (cf. MNG-2045).

All none test dependencies of foo will be included automatically. If Foo is dependent on bar’s tests so you need to apply the same approach for Foo/Bar See (Rich’s answer) otherwise foo will not pass test-compile
No its a bunch of normal dependencies. I just liked the idea of e.g. specifing in foo which database to use in integration testing and keep bar clear of the concrete db name.
I believe this answer is incorrect. <classifier>tests</classifier> seems to work with maven 3.0.3 at least, so perhaps it is the <type>test-jar</type> solution that is "out of date"?
This answer worked for me equally as well as Rich Sellers'. Maven 3.3.9.

krosenvold · Accepted Answer · 2008-12-11 17:25:37Z

Usually this is solved by building and deploying modulename-test.jar files in addition to the regular modulename.jar file. You deploy these to repos like regular artifacts. This is not totally flawless, but works decently for code artifacts.

Then you would add test scoped dependencies to the test-jars to other modules.

You can also solve this by putting test scoped artifacts in "main" scope in a separate module of its own and then include this in regular test-scope in other modules. This solution does not work very well in a multi-module build where each module exports some test artifacts, since you basically get 2N modules.

A lot of us actually give up on both of these solution when we realize that the number of classes is fairly limited and there are problems associated with both of these solution. We just put them in an appropriately named package in "main" scope. I just keep forgetting why the two first solutions are a pain.

Collectives™ on Stack Overflow

Test class extending test class in dependency module

3 Answers 3

4 Comments

5 Comments

Comments

Linked

Hot Network Questions