Big changes to JUnit 5.2
JUnit 5 arrived last year and we’ve been happy to see all the changes to this programmer-friendly testing framework for Java. Today, we take a look at what’s in JUnit 5.2: build tool enhancements, improvements for parameterized tests, and more.
JUnit 5 was the result of approximately two years of work when it was released last year. Deemed to have “the potential to redefine testing on the JVM”, JUnit 5 consisted of three different modules: JUnit Platform, JUnit Jupiter, and JUnit Vintage.
These three projects served as the foundation for launching testing frameworks on the JVM. Between all these options, the JVM is sorted for any kind of testing needed.
Big changes are in store for the 5.2 release, building on the momentum from last year’s major release. The biggest change? Build tool enhancements to support the new modular architecture.
Now, there is a new BOM designed to simplify version management and dependency management concerns. After all, in JUnit 5, developers are now managing multiple dependencies. While developers will need to configure their dependency management to point to it, doing so simplifies the circus of managing all those dependencies.
Additionally, JUnit 5.2 now offers support for Surefire 2.21.0, making it possible for JUnit 5 tests to run in Java 9 and 10 ecosystems. (The previous version of JUnit skipped this Surefire support due to memory leak problems on the other end.) This also includes support for passing in null/blank properties.
JUnit 5.2 also now supports the failsafe plugin, which is designed to run integration tests while the Surefire plugin runs unit tests. Basically, when it fails, it does so in a safe and controlled manner. While the failsafe plugin offers a few additional life-cycle steps in the set up and tear down for any integration test, it does so in a configuration similar to the Surefire plugin.
Parameterized tests have been a big part of the JUNIT 5 release; this continues in 5.2. This release continues the trend of making it easier to write a parameterized test.
@MethodSource used to be located within the same class as
@ParameterizedTest. Now, it can be in an external class. Why? Well now, it is easier to execute a large number of scenarios with an external
@MethodSource. Additionally, it improves test class readability and the separation of concerns.
In other changes,
@CsvSource has seen a number of improvements with the new ArgumentsAccessor. Format changes are no longer the bane of developers in JUnit 5.2. Now, the method signature for a test case no longer needs to match the shape of the record it is passed in. Nor, for that matter, does the composition of the test object have to happen in every test case.
Getting JUnit 5.2
If you’d like to get JUnit 5.2, head over to the JUnit website for more information.