Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 232 posts at DZone. You can read more from them at their website. View Full User Profile

Reuse Test Classes Across Different Projects

  • submit to reddit

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.


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:


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:

To go further:

Published at DZone with permission of Nicolas Frankel, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


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

Not necessarily, for example integration testing

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.