Home > Java > Re-use your test classes across different projects

Re-use your 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 aim 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 get 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 projet 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 to Maven to pick the attached artifact and not the main one. Also, note although you could configure the dependency with a classifier instead of a type, the current documentation warns about possible bugs and favor the type configuration.

To go further:

email
Send to Kindle
Categories: Java Tags: ,
  1. August 26th, 2012 at 11:42 | #1

    There is also another situation where we want to share test utilities but not the tests themselves. This is one solution but we try to avoid it as much as we can:

    1. The configuration you provided still ships other test resources that you may not want in your classpath (logging configuration, etc). Yes you can exclude those but it’s tedious
    2. Unless you have a clear guideline for separating test utilities from tests themselves, you end up with more information than what you woud like to share eventually

    We try to separate this as much as possible by creating a model module and a test infrastructure module (relying on the model but not the implementation). That way we can use the API to create tester and test helpers without having to deal with the test-jar thing. And other modules benefit from the test infrastructure.

    Of course, I’d love maven to support a third source types (main, test and something else in between).

  1. No trackbacks yet.