Reuse Test Classes Across Different Projects
Sometimes, you need to reuse your test classes across different projects. These are two use-cases that I know of:
- Utility classes that create relevant domain objects used in different modules
- Database test classes (ans resources) that need to be run in the persistence project as well as the integration test project
Since I’ve seen more than my share of misuses, this article aims to provide an elegant solution once and for all.
Creating the test artifact
First, we have to use Maven: I know that not everyone is a Maven fanboy, but it gets the work done – and in our case, it does it easily. Then, we configure the JAR plugin to attach tests. This will compile test classes and copy test resources, and package them in an attached test artifact.
<project>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>The test artifact is stored side-by-side with the main artifact once deployed in the repository. Note that the configured test-jar is bound to the install goal.
Using the test artifact
The newly-created test artifact can be expressed as a dependency of a project with the following snippet:
<dependency> <groupId>ch.frankel.blog.foo</groupId> <artifactId>foo</artifactId> <version>1.0.0</version> <type>test-jar</type> <scope>test</scope> </dependency>
The type has to be test-jar instead of simply jar in order for Maven to pick the attached artifact and not the main one. Also, note that although you could configure the dependency with a classifier instead of a type, the current documentation warns you about possible bugs and favors the type configuration.
Original article: http://blog.frankel.ch/re-use-your-test-classes-across-different-projects
To go further:
- Maven guide to using attached tests
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)






Comments
Wal Rus replied on Mon, 2012/08/27 - 5:42pm
It's clear pointer that you've got a library on your hands that needs to be built and tested separately. Projects using the library shouldn't include the tests of the library, they should include tests that test projects. The library should already come tested.
Dale Wyttenbach replied on Wed, 2012/08/29 - 10:34am
in response to:
Wal Rus