JUnit 5 Architecture

JUnit 5 Architecture

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.
  • A mechanism for discovering and running the tests.
  • An API to allow the easy interaction with IDEs and tools and to run the tests from them.

 

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.
  • JUnit Jupiter, the combination of the new programming model and extension model for writing tests and extensions in JUnit 5. The name has been chosen from the fifth planet of our Solar System, which is also the largest one.
  • JUnit Vintage, a test engine for running JUnit 3 and JUnit 4 based tests on the platform, ensuring the necessary backwards compatibility.
modular architecture of JUnit 5.jpg

 

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.
  • junit-platform-console, which provides support for discovering and executing tests on the JUnit Platform from the console.
  • junit-platform-console-standalone an executable JAR with all dependencies included. It’s used by Console Launcher, a command-line Java application that lets you launch the JUnit Platform from the console. For example, it can be used to run JUnit Vintage and JUnit Jupiter tests and print test execution results to the console.
  • junit-platform-engine, a public API for test engines.
  • junit-platform-launcher, a public API for configuring and launching test plans, typically used by IDEs and build tools.
  • junit-platform-runner, a runner for executing tests and test suites on the JUnit Platform in a JUnit 4 environment.
  • junit-platform-suite-api, which contains the annotations for configuring test suites on the JUnit Platform.
  • junit-platform-surefire-provider, which provides support for discovering and executing tests on the JUnit Platform using Maven Surefire.junit-platform-gradle-plugin, which provides support for discovering and executing tests on the JUnit Platform using Gradle.

Interested in Java?

Check out our trainings
Tudose, Florin-Catalin , Java Champion; Java Chapter Lead; Author at Pluralsight and Manning

Tudose, Florin-Catalin Tudose author linkedin

Java Champion; Java Chapter Lead; Author at Pluralsight and Manning

Tudose, Florin-Catalin , Java Champion; Java Chapter Lead; Author at Pluralsight and Manning

Tudose, Florin-Catalin Tudose author linkedin

Java Champion; Java Chapter Lead; Author at Pluralsight and Manning