Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Sharing Test Classes Between Multiple Modules in a Multi-module Maven Project

DZone's Guide to

Sharing Test Classes Between Multiple Modules in a Multi-module Maven Project

Using Maven to effectively test software when test classes are not already packaged by Maven.

· DevOps Zone ·
Free Resource

The need for DevOps innovation has never been greater. Get the results from over 100 business value assessments in this whitepaper, Digital Darwinism: Driving Digital Transformation, to see the positive impact of DevOps first hand.

Scenario

Project A has a class generated in its test branch. Project B (or C, D, etc..) wants to utilize the class generated in Project A’s test scope.

The Problem

Typically classes in the test branch are not packaged by Maven, therefore, Project B has no means to find the class/resource in Project A.

Solution

Edit the package phase of the jar plugin in Project A so a jar file containing the compiled test classes can be made available to other modules/projects.

Addition to the build section in Project A:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-jar-plugin</artifactId>
  <version>2.6</version>
  <executions>
    <execution>
      <id>Jar Package</id>
      <phase>package</phase>
      <goals>
        <goal>jar</goal>
      </goals>
    </execution>
  <execution>
  <id>Jar Tests Package</id>
  <phase>package</phase>
  <goals>
  <goal>test-jar</goal>
  </goals>
  </execution>
  </executions>
</plugin>

In this example, two jars are created. One will be the typical packaged product associated with the “jar” goal of the “package” phase (a jar file containing compiled source under “src/main/java”).  A second jar is constructed containing the compiled source under “src/test/java” this is associated with the “test-jar” goal of the p”package” phase.

Files Generated

  • ExampleJar-0.0.1-SNAPSHOT.jar

  • ExampleJar-0.0.1-SNAPSHOT-tests.jar

Project B will contain 2 references to the ExampleJar dependency. One for the compilation process and another for the “test” scope of Project B.

Note: if the only requirement is for test dependencies than the dependency that is under the default scope wouldn’t be needed.

Example of how to reference the “test-jar” in Project B:

<dependency>
  <groupId>com.example</groupId>
  <artifactId>ExampleJar</artifactId>
  <version>${project.parent.version}</version>
</dependency>

<dependency>
  <groupId>com.example</groupId>
  <artifactId>ExampleJar</artifactId>
  <version>${project.parent.version}</version>
  <type>test-jar</type>
  <scope>test</scope>
</dependency>

Additional Points

Generally it’s not a good idea for test source bases to have dependencies. This scenario came to me while converting projects to Maven and mocks being shared amongst different projects.

Another way to solve this problem would be to place mocks classes and other test resources into a compiled dependency that is available to all modules.

Interested in Kubernetes but unsure where to start? Check out this whitepaper, A Roundup of Managed Kubernetes Platforms from Codeship by Cloudbees, for an overview and comparison of Kubernetes platforms. 

Topics:
java ,maven

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}