JUnit 5 – Setup

With JUnit 5 still under development, tool support is not at 100% yet and setting JUnit 5 up in your favorite one still requires a little work. Here’s how to do it in IntelliJ, Eclipse, Maven, Gradle, or, if everything else fails, on the command line.

As we speak, the work on JUnit 5 goes on. Throughout 2016 various Milestones were published and a general availability release is planned for sometime in summer 2017. I am exploring the next generation of testing on the JVM with in a series of short posts:

(If you'd rather hear me talk about JUnit 5, check out the recent vJUG session or my presentation at JavaZone.)


This series is based on the pre-release version Milestone 3 and will get updated when a new milestone or the general availability release gets published.

Most of what you will read here and more can be found in the emerging JUnit 5 user guide (that link went to the Milestone 3 version - you can find the most current version here). The code samples I show here can be found on GitHub.

Writing Tests

The API for writing tests is contained in the junit-jupiter-api artifact. Including it in your project with your favorite build tool is all it takes to write tests.

  • Group ID: org.junit.jupiter
  • Artifact ID: junit-jupiter-api
  • Version: 5.0.0-M3

To have something to work with, let’s quickly create our first test:

See ma, no public! Cool, right? I won’t go into it here, check out the post on basics for more details.

Running Tests

With JUnit 5 being bleeding edge, native tool support is not ideal, yet. But there are early access implementations and workarounds to get everything running.

JUnit 4 Runner

A test runner called JUnitPlatform can be used to run new tests as part of a JUnit 4 run. You will find it in its own artifact, which you have to add to your project:

  • Group ID: org.junit.platform
  • Artifact ID: junit-platform-runner
  • Version: 1.0.0-M3
  • Scope: test

The runner will call into the engine that actually runs the JUnit 5 tests. The engine also has its own artifact that you have to add:

  • Group ID: org.junit.jupiter
  • Artifact ID: junit-jupiter-engine
  • Version: 5.0.0-M3
  • Scope: test runtime

To run all tests in a project, it is easiest to create a test suite for them:

Note that the class has to be a regular JUnit 4 test class, i.e. it has to adhere to the common naming convention and must be public. The @SelectPackages-annotation interprets packages as a hierarchy so it runs all tests in all packages prefixed with org.codefx.demo.junit5. If you prefer, you can use the same runner directly on the JUnit 5 test classes; in that case they have to be public.

Now we’re done! Your favorite IDE and build tool will happily run the classes annotated with @RunWith(JUnitPlatform.class) and hence the new JUnit 5 tests.

Due to the detour through JUnit 4, some features may not work, e.g. IDEs won’t run individual test methods. But for the time being I found this an acceptable and tool independent solution.

IDE Support

Since 2016.2 IntelliJ IDEA has basic JUnit 5 support. It is not perfect and will have to keep catching up with a moving target but it works and makes playing around with the new JUnit much easier. To run tests written against Milestone 3 you have to use 2016.3.1.

The Eclipse team is working on native support and if you don’t mind a little configuration you can try it out with the Eclipse 4.7 M4 build following these steps.

Build Tool Support

The JUnit team already put in some work to implement build tool support for JUnit 5, i.e. without the detour via JUnit 4. A rudimentary Gradle plugin and Maven Surefire provider are up and running and there are sample projects for both (Gradle, Maven). For more details have a look at the user guide.

In the last months the Maven and the Gradle teams have taken over (Maven #1206, Gradle #1037) and we can expect both build tools to support JUnit 5 soonish.

Command Line For The Win!

In case all of this is too fancy for you, try the console launcher, which lets you run the tests directly from the command line. To get hold of it you can download this ZIP.

Unfortunately it doesn’t work out of the box because it needs the junit-jupiter-api and junit-jupiter-engine artifacts mentioned above. One way to get it to work is manually adding them to the class path:

This is pretty cumbersome but you can of course put the command and its class path options for the artifacts into a separate script file. Alternatively, and that’s what I did, you can drop the artifacts into lib and edit the class path definition in the script in bin to CLASSPATH=$APP_HOME/lib/* to make it work.

Ignoring dependencies (e.g. on your production code, your own extensions or other test libraries) you can then use it as follows:

To include dependencies add them to the class path after -cp. If you’re doing this in a Maven project, your command might look like this:


As you might have noticed, JUnit 5 occupies new namespaces: org.junit.jupiter, org.junit.platform, and org.junit.vintage (which we didn’t see yet). I explain their meaning in a post dedicated to JUnit’s architecture – for now this only means that there will be no conflicts when different JUnit versions are used in the same project.

Indeed, a project can contain and run tests from different versions without problems, which allows a slow migration to JUnit 5. We will revisit this topic when we’re exploring migration paths (stay tuned).

Assertion libraries like Hamcrest and AssertJ, which communicate with JUnit via exceptions, will continue to work in the new version. Check out the complete version of HelloWorldTest for an example using Mockito and AssertJ.


For our JUnit 5 setup we’ve included junit-jupiter-api, junit-jupiter-engine, and junit-platform-runner in our project, written a first minimal test case, and ran it with as part of a JUnit 4 test suite.

The next post explores the basics of how to write tests in JUnit 5.

Share & Follow

You liked this post? Then share it with your friends and followers!
And if you like what I'm writing about, why don't you follow me?

Other Posts