Maven – Classloading issues in maven2 with JUnit

junitmaven-2

I have a project that builds with maven2 and runs a series of JUnit test cases against the code. This has worked fine up until this point, where I now have 2 tests that must run in a certain sequence for things to work correctly, let's say TestA and Test (A then B). Unfortunately, maven2 doesn't understand this, so I'm looking for a way of convincing it that it needs to run the tests in this order.

The problem is that I'm setting some final static fields in TestB, but I'm doing this from TestA, which itself uses those fields, and successful execution of the test depends on those fields being set to their new values (there is absolutely no way around this, otherwise I would have taken that road long before now). So, it is imperative that TestA loads first, and it will of course cause TestB to be loaded when tries to access it. However, maven2 has decided that it will run TestB then TestA, which means those final fields are already set and cannot be changed.

So what I'm looking for is either a way to specify the order in which the tests are executed (A then B, every time), or a way to easily cause TestB to be reloaded by whichever classloader that JUnit uses.

EDIT – one other option might be some option like the old JUnit GUI tool has, that causes all classes to be reloaded for each test. I have looked and looked and not found such a flag in the maven junit plugin, if such a thing exists, then that would also work.

Best Answer

The test order in JUnit is intentionally undefined, this is not a Maven issue and it's probably just luck that your tests were running OK up until now.

Sal's answer addresses your question directly, however forking the JVM on each test for large test counts can hugely increase your build time.

An alternative approach would be to use a testing library such as PowerMock (it currently works with EasyMock and Mockito) to clear the static fields in TestB's initialisation, this avoids the need for any JVM forking, and ensures your tests are portable.

From the PowerMock website:

PowerMock is a framework that extend other mock libraries such as EasyMock with more powerful capabilities. PowerMock uses a custom classloader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods, removal of static initializers and more. By using a custom classloader no changes need to be done to the IDE or continuous integration servers which simplifies adoption. Developers familiar with EasyMock will find PowerMock easy to use, since the entire expectation API is the same, both for static methods and constructors. PowerMock extends the EasyMock API with a small number of methods and annotations to enable the extra features. From version 1.1 PowerMock also has basic support for Mockito.

Problems of popular approaches

Most of the answers you'll find around the internet will suggest you to either install the dependency to your local repository or specify a "system" scope in the pom and distribute the dependency with the source of your project. But both of these solutions are actually flawed.

Why you shouldn't apply the "Install to Local Repo" approach

When you install a dependency to your local repository it remains there. Your distribution artifact will do fine as long as it has access to this repository. The problem is in most cases this repository will reside on your local machine, so there'll be no way to resolve this dependency on any other machine. Clearly making your artifact depend on a specific machine is not a way to handle things. Otherwise this dependency will have to be locally installed on every machine working with that project which is not any better.

Why you shouldn't apply the "System Scope" approach

The jars you depend on with the "System Scope" approach neither get installed to any repository or attached to your target packages. That's why your distribution package won't have a way to resolve that dependency when used. That I believe was the reason why the use of system scope even got deprecated. Anyway you don't want to rely on a deprecated feature.

The static in-project repository solution

After putting this in your pom:

<repository>
    <id>repo</id>
    <releases>
        <enabled>true</enabled>
        <checksumPolicy>ignore</checksumPolicy>
    </releases>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
    <url>file://${project.basedir}/repo</url>
</repository>

for each artifact with a group id of form x.y.z Maven will include the following location inside your project dir in its search for artifacts:

repo/
| - x/
|   | - y/
|   |   | - z/
|   |   |   | - ${artifactId}/
|   |   |   |   | - ${version}/
|   |   |   |   |   | - ${artifactId}-${version}.jar

To elaborate more on this you can read this blog post.

Use Maven to install to project repo

Instead of creating this structure by hand I recommend to use a Maven plugin to install your jars as artifacts. So, to install an artifact to an in-project repository under repo folder execute:

mvn install:install-file -DlocalRepositoryPath=repo -DcreateChecksum=true -Dpackaging=jar -Dfile=[your-jar] -DgroupId=[...] -DartifactId=[...] -Dversion=[...]

If you'll choose this approach you'll be able to simplify the repository declaration in pom to:

<repository>
    <id>repo</id>
    <url>file://${project.basedir}/repo</url>
</repository>

A helper script

Since executing installation command for each lib is kinda annoying and definitely error prone, I've created a utility script which automatically installs all the jars from a lib folder to a project repository, while automatically resolving all metadata (groupId, artifactId and etc.) from names of files. The script also prints out the dependencies xml for you to copy-paste in your pom.

Include the dependencies in your target package

When you'll have your in-project repository created you'll have solved a problem of distributing the dependencies of the project with its source, but since then your project's target artifact will depend on non-published jars, so when you'll install it to a repository it will have unresolvable dependencies.

To beat this problem I suggest to include these dependencies in your target package. This you can do with either the Assembly Plugin or better with the OneJar Plugin. The official documentaion on OneJar is easy to grasp.

Best Answer

Related Solutions

Java – How to assert that a certain exception is thrown in JUnit 4 tests

Java – add jars to Maven 2 build classpath without installing them