The JUnit 5 framework has been designed to be consumed by different programmatic clients. The first group of clients are Java tests. These tests can be based on JUnit 4 (tests which use the test legacy programming model), JUnit 5 (tests which use the brand new programming model), and even other kinds of Java tests (third party). The second group of clients are build tools (such as Maven or Gradle) and IDEs (such as IntelliJ or Eclipse).

In order to achieve the integration of all these pieces in a loosely coupled manner, JUnit 5 was designed to be modular. As depicted in the following picture, the JUnit 5 framework is composed of three major components, called Platform, Jupiter, and Vintage:

The high-level components of the JUnit 5 architecture are enumerated as follows:

• The first high-level component is called Jupiter. It provides the brand-new programming and extension model of the JUnit 5 framework.
• In the core of JUnit 5, we find the JUnit Platform. This component is aimed to become the foundation for any testing framework executed in the JVM. In other words, it provides mechanisms to run Jupiter tests, legacy JUnit 4, and also third-party tests (for example, Spock, FitNesse, and so on).
• The last high-level component of the JUnit 5 architecture is called Vintage. This component allows running legacy JUnit tests on the JUnit Platform out of the box.

Let's take a closer look at the details of each component to find out their internal modules:

As can be seen in the picture preceding, there are three types of module:

• Test APIs: These are the modules facing users (that is, software engineer and testers). These modules provide the programming model for a particular Test Engine (for example, junit-jupiter-api for JUnit 5 tests and junit for JUnit 4 tests).
• Test Engines: These modules allow to execute a kind of test (Jupiter tests, legacy JUnit 4, or other Java tests) within the JUnit Platform. They are created by extending the general Platform Engine (junit-platform-engine).
• Test Launcher: These modules provide the ability of test discovery inside the JUnit platform for external build tools and IDEs. This API is consumed by tools such as Maven, Gradle, IntelliJ, and so on, using the junit-platform-launcher module.

As a result of this modular architecture, the JUnit framework exposes a set of interfaces:

• An API (Application Programming Interface) to write tests, the Jupiter API. The detailed description of this API is what it is known as the Jupiter programming model and it is described in detail in chapters 3, JUnit 5 Standard Tests and chapter 4, Simplifying Testing With Advanced JUnit Features of this book.
• An SPI (Service Provider Interface) to discover and execute tests, the Engine SPI. This SPI is typically extended by test engines, which in the end provide the programming models to write tests.
• An API for test discovery and execution, the Launcher API. This API is typically consumed by programmatic clients, that are IDEs and build tools.