Next Milestone For JUnit 5

In the unlikely case that you didn’t yet hear about JUnit 5, yet, let me quickly introduce it. If you know it, just skip the next section, so I can tell you something you don’t already know.

What do you mean, JUnit 5?

In 2015 a couple of JUnit core committers and a few other developers with interest in the project decided that it was time for a rewrite. Reasons:

The need for a better architecture that ensures JUnit’s maintainability and gives it room for evolution.

The need for a better extension model that does away with the limitations and complexities of runners and rules.

Lambdas!

Born was JUnit Lambda, which in fall 2015 collected enough paid development time from employers and enough funding from the crowd for a concerted, six-week effort to bootstrap JUnit’s next version. Out came a prototype in November 2015, followed by an alpha version in February 2016, two Milestones (M1 and M2) in July, and the third milestone on November 30th.

It is likely that at least two more milestones will follow before a general availability release can be expected. My best guess for when that will be is second or third quarter 2017.

To get an impression what the project looks like and where it wants to go, check out the state of the union, that I wrote in October. It’s not entirely up-to-date anymore but so far only a few details changed. If that’s too much effort for now, imagine JUnit 4 with a bunch of thoughtful improvements. On the surface that’s all that changed — the real gems lie deeper.

Tell Me Something I Don’t Already Know!

Ok, let me try. Did you know…

… that there is an excellent user guide (M3 and development version) that covers most of what you ever need to know in only 11'000 words? Also: Javadoc (M3, current).

… that ZeroTurnaround published a nice little JUnit 5 cheat sheet? In case you’re still new to JUnit 5, the article and sheet are good ways to get started.

… that after IntelliJ, Eclipse is the second IDE with native support for JUnit 5? Early access is available in 4.7 M3.

… that the Maven team recently adopted the prototypical Surefire provider the JUnit team implemented? Native Maven support can’t be too far off now (although the issue in Apache’s tracker shows little activity). Unfortunately I heard nothing of the kind from the Gradle project, which according to my search does not even haven an issue for JUnit 5 yet. That being said, there is also a prototypical Gradle plugin and like the Surefire provider, it works pretty well.

… that running tests written in versions 4 and 5 side by side is a breeze? For an in-depth coverage of this, check out Mert Caliskan’s article in the Java Magazine.

… that some JUnit 4 rules work in JUnit Jupiter? Currently the rules ExternalResource , Verifier , and ExpectedException as well as all of its subclasses are supported and can be used in tests written against the Jupiter API. For details have a look at the guide.

And finally, did you know that the JUnit team loves to hear from you? If you have an idea for how to improve JUnit or want to give feedback after trying it out, feel free to ping them on Twitter or, preferably, open an issue. If you feel like contributing, all the better! There’s an up-for-grabs label to help you find tasks to get started on.

What’s New In Milestone 3?

Since M3 was released so recently, let’s have a quick glance at the release notes. Most of the changes occurred in the JUnit Platform (the what? Read up on architecture), which by its nature is less thrilling to users like us. Still, there are a couple of interesting things hidden there:

By default, every class that ends in either Test or Tests is considered for test execution.

or is considered for test execution. Including and excluding tests by tags, package, or class names was implemented / improved.

If you’ve been using the console launcher, note that a couple of command line flags have new names.

To improve support for alternative test engines, a new annotation @Testable was introduced that tools (particularly IDEs) should look for when trying to determine what might be executable as a test.

Jupiter, which contains the API we write tests against, saw much fewer substantial changes — here are the more interesting ones:

The new assertions assertTimeout and assertTimeoutPreemptively can be used to fail or even abandon tests that take too long.

and can be used to fail or even abandon tests that take too long. @BeforeAll and @AfterAll may now be declared on static methods in interfaces.

and may now be declared on static methods in interfaces. Limited support for JUnit 4 rules but we already covered that above.

Gimme Moar!

Ok, ok, jeez… If you’re interested in a deep dive into the extension model, including some implementation details, read my article in the Java Magazine. Last but not least, there are Devoxx BE talks by myself and by Sam Brannen. His is double the length and he works on the project and actually knows what he’s talking about, so if you can spare the hour, watch his talk.