7 Reasons to Consider JUnit 5

the latest version of junit is just around the corner. according to the official roadmap the final release is planned for q3 2017. at the moment of writing, 4 milestones have been published and a few more are planned before release candidates, but it doesn’t mean you have to wait several months to make use of junit 5. the goal of this post is to encourage you in seven points to start playing with the new version the framework right away.

1. ready to use

it’s not unusual, when a new version of language, application server, or library comes to light, that developers tend to postpone learning to a time when the industry is ready to adopt the changes. just look at javascript. two years after the release of the es2015 specification, web browsers are still struggling to support all language features. transpilers did a great job to help with popularization but, as a side effect, introduced an additional step in the development process.

the junit 5 team facilitates the adoption of the new version from the beginning. intellij idea already runs tests natively within the ide. eclipse introduced its beta support as well. the two most popular build tools, maven and gradle, handle junit 5 tests without issue. moreover, if you use some less popular tool, a console launcher will help you to execute tests automatically. last but not least, there is also a dedicated junit 4 runner that allows running new tests in environments that support only the previous version. as you can see, junit 5 gives plenty of choices.

2. easy to learn

at the first glance, the new api (also known as junit jupiter) strongly resembles its predecessor. the level of similarity is so high that you might even think that creating a new major release of the framework for such cosmetic changes is a considerable abuse. the most popular assertions are still the same. the only differences are in the package they are placed and the order of parameters in overloaded variants. widely known annotations changed their names but are still responsible for the same actions. if you are familiar with junit 4 you can grasp the basics of junit 5 within a few minutes.

at this point, you may ask, if it is so similar to the previous version, then why you should bother? in short, junit 5 is like a superset of the predecessor and has much more to offer.

3. brand new features

once you familiarize yourself with the basics (approx. 15 minutes) you can move to the next level. depending on your needs, you should consider experimenting with:

• new assertions.
• nested test classes: interesting not only for behavior driven development followers
• dynamic tests: generating test cases at runtime
• test extensions: allowing you to redefine the behavior of tests and test classes in a reusable and pluggable way

4. solving junit 4's problems

nothing is perfect, including junit 4. there are several known different size issues that have been worked around by the community. let’s quickly look over these problems.

4.1. exception verification

the flagship example of all aforementioned issues is exception checking. consider the following junit 4 test:

@test(expected = illegalargumentexception.class)
public void shouldthrowexception() throws exception {
    task task = buildtask();
    localdatetime onehourago = localdatetime.now().minushours(1);
    task.execute(onehourago);
}

imagine we want to test if the execute() method of the task object throws the illegalargumentexception if the given argument is in the past. the test looks fine, but what happens if the exception is thrown by the buildtask() method? the test will give us a false positive. we should check if the exception occurs exactly in the place where it is expected , not the whole test body. junit 5 gives you assertthrows() out-of-the-box, which gracefully handles the described problem as in the following snippet:

@test
void shouldthrowexception() throws exception {
    task task = buildtask();
    localdatetime onehourago = localdatetime.now().minushours(1);
    assertthrows(illegalargumentexception.class,
                 () -> task.execute(onehourago));
}

4.2. timeout measurement

in addition, a similar set of assertions has been provided to verify timeouts in the code provided within a lambda expression. you don’t have to worry that the setup part of a test will have an impact on the measured execution time. now you can choose which code is measured. also, there is an option to stop execution when the timeout is exceeded or to continue and measure the actual time required to execute tested code.

@test
void shouldtimeout() throws exception {
    expensiveservice service = setupservice();
    asserttimeout(ofseconds(3), () -> {
        service.expensivemethod();
    });
}

4.3. parameterized tests

if you don’t like the fact that junit4 requires using test class fields for parameterized tests, the new approach proposed in junit 5 will surely meet your needs. parameters are now connected directly to a test method and nothing prevents you from putting different parameterized tests in a single class, which isn’t possible in junit 4.

test parameters can be supplied by an array of sources, including csv-like strings, external csv files, enums, factory methods, and dedicated provider classes. string literals are automatically converted into numerous types and you can also provide your custom converters if the built-in ones don’t cover your use cases.

4.4. multiple runners

probably the greatest issue of junit 4 is its inability to use several test runners in a single class. limitations of parameterized tests or nested test classes can be solved with runners, but they cannot be used with others. we are forced to pick just one. for instance, before spring 4.2, every test depended on your application context had to use the springjunit4classrunner. now you can use a dedicated rule to work around the issue so you can use a different runner, but still only one. junit 4 wasn’t designed with extensibility in mind and it pays the price of backward compatibility. the junit 5 team has chosen a different path and planned the architecture of the new version to solve this problem thanks to the already mentioned extensions.

5. simple migration

do you already have hundreds of tests in your current project and shivering at the thought of rewriting them? relax. the junit 5 team thought about different options for a migration. first things first, junit 4 and 5 can both be used in one project without conflicts . once you add the new version to a project’s dependencies, you have two alternatives for running tests together.

the least invasive option is to write new tests with the junit 5 api and run them with a dedicated junitplatform runner for junit 4 . but wait, didn’t we just say those runners are the crux of the matter? well, the runner has its limitations and supports only a subset of features introduced by the new version. but it’s good enough to start using the latest api in a living project. the fastest way to learn is to practice on a real problem, right?

the second alternative is to promote junit 5 as a master runner of all tests. besides all the best features of the framework, you will get the ability to execute old tests within the new platform, but with one little reservation. because of the conceptual differences, only selected rules from junit 4 are supported in junit 5. before you take a leap of faith into the junit 5 platform, spend some time to familiarize yourself with the limitations .

6. opportunity to contribute

since the new version is still under development, there is no better moment to request a feature that might be useful. it is you, the user of the framework, who knows best what is expected from a dependency you put into your project. every reasonable idea may be reported in the issue tracker of the junit 5 project.

but before you open a new ticket, make sure that the framework doesn’t already have what you are looking for. don’t waste the time of the team for issues that have already been solved or don’t add much value. however, if you have a good proposal, don’t hesitate and write a descriptive overview. no one said that you can contribute to open source only by writing code. ideas also matters. all issues can be found here .

7. future of jvm testing

junit 5 isn’t just another pretender to the testing framework throne. the architecture of junit 5 has been greatly altered — not only because of the breaking changes in the public api and the introduction of the extension model. one of the goals was to create a base platform for jvm testing frameworks. what does that mean? let’s take a glance at the following diagram.

as you can see, just like onions and ogres, junit 5's architecture has layers. the core of the framework is the platform. ides and build tools as clients communicate with the platform in order to execute tests in a project. available testengine implementations called by the platform discover and run tests, and the unified output is reported through the platform back to clients.

the key point is extensibility, but not at the test class level as mentioned before. it is extensibility at the level of the whole testing platform. any framework can run its tests on the junit platform as long as it provides an implementation of the testengine interface. with a little effort, by covering this single integration point, that imaginary framework will get the support of all ides and build tools that are already integrated with the platform. the barriers to entering the industry for newly invented frameworks will be much lower because they won’t have to provide support for aforementioned ides and tools.

but what do all these changes give you as a developer? it should be much easier to convince your manager, lead developer, or whoever blocked your last suggestion to experiment with an exotic testing framework that said framework has integration with all major tools on the jvm development market. junit vintage, which executes old junit 4 tests, is a prime example. this is a proven concept.

not convinced yet?

even if you are not an early adopter type of developer, you should still keep an eye on the changes introduced in the newest version of junit. with all the advantages that junit 5 brings and the fame of the predecessor, its way into the mainstream is just a matter of time. for those who don’t want to experiment on their real applications, a side project might be a great option to get to know with the new junit jupiter api. if you find any issue or have a comment, feel free to report it. open source is created by the whole community, not only by the core project development team. it is up to you whether you want to become a contributor.