Abstract: This article discusses the new architecture of JUnit 5, the shortcomings of the previous JUnit 4 version, and how the modular approach changed things and the advantages it has come with. It also shows you how to migrate the JUnit 4 code to JUnit 5, capitalizing the new features.

1. JUnit 5 modularity

JUnit 5 means it is time for a new approach. It hasn’t come instantly; it required reflection, and the shortcomings of JUnit 4 are a good input for the needed improvements. Architects know the problems, and they decided to go on the path of reduced sizes and modularity.

A new approach, a modular one, was necessary in order to allow the evolution of the JUnit framework. Its architecture had to allow JUnit to interact with different programmatic clients, with different tools and IDEs. The logical separation of concerns required:

  • An API to write tests, dedicated mainly to the developers.

As a consequence, the resulting JUnit 5 architecture contained three modules (fig. 1):

  • JUnit Platform, which serves as a foundation for launching testing frameworks on the JVM (Java Virtual Machine), also provides an API to launch tests from either the console, IDEs, or build tools.
Figure 1 The modular architecture of JUnit 5

2. JUnit 5 Platform

Going further with the modularity idea, we’ll have a brief look at the artifacts contained into the JUnit 5 Platform (fig. 2):

  • junit-platform-commons, an internal common library of JUnit, intended solely for usage within the JUnit framework itself. Any usage by external parties isn’t supported.

Interested in Java? Check out our trainings.

Catalin Tudose
Java and Web Technologies Expert

Originally published at https://www.luxoft-training.com.