JUnit 5 – Setup

In November 2015 the JUnit Lambda team presented their prototype. Since then the project rebranded itself as JUnit 5 and released an alpha version in February 2016. We’ll explore it 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 DevoxxPL.)

This one discusses the JUnit 5 setup so you can write code against the new API and run tests in your IDE or with your build tool.

Overview

This series is based on the pre-release version Milestone 2, which is of course subject to change. The posts 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 2 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-M2

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 at the moment but the next post will discuss this (and other basics) so stay tuned.

Running Tests

With JUnit 5 being cutting edge, native tool support is lacking. But there are preliminaries 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-M2

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-M2

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 the classes annotated with @RunWith(JUnitPlatform.class) and hence the new JUnit 5 tests.

Until true JUnit 5 support comes around, some features may not work, e.g. IDEs won’t run individual test methods. But for the time being I found this to be the most straight-forward 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.

The Eclipse team is working on native support.

Build Tool Support

The JUnit team is already hard at 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. Both projects are planned to be handed over to the respective communities at some point.

There are sample projects for both (Gradle, Maven). For more details have a look at the user guide.

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. I had to drop the junit-jupiter-api and junit-jupiter-engine artifacts mentioned above 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 use it as follows:

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

Compatibility

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). We will discuss their meaning soon – 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 JUnit’s new architecture.

Test 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.

Reflection

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 will explore the basics of how to write tests in JUnit 5.

Share & Follow

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

Other Posts