Software testing has changed a lot since the first release of JUnit 4 in 2006. Since then, not only have Java and the JVM has evolved, but also our testing needs matured. We are not writing just unit tests anymore. Instead, in addition to verifying a single piece of code, software engineers and testers demand other kinds of tests, such as integration and end-to-end tests.

In addition, our expectations about testing frameworks have grown. Nowadays, we demand advanced capabilities for these frameworks, such as extensibility or modularity, to name a few. In this section, we discover the main limitations of JUnit 4, the vision of JUnit 5, and the community supporting its development.

According...

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...

At the time of writing, Jupiter tests can be executed in several ways:

• Using a build tool: Maven (implemented in the module junit-plaform-surefire-provider) or Gradle (implemented in the module junit-platform-gradle-plugin).
• Using the Console Launcher: A command-line Java application that allows to launch the JUnit Platform from the console.
• Using an IDE: IntelliJ (since version 2016.2) and Eclipse (since version 4.7, Oxygen).

As we are going to discover, and due to the modular architecture of JUnit 5, we need to include three dependencies in our projects: one for the Test API (to implement tests), an other for the Test Engine (to run tests), and the last one of the Test Launcher (to discover tests).

As introduced before, Jupiter is the name given to the new programming model of JUnit 5, described in detail in chapter 3, JUnit 5 standard tests and chapter 4, Simplifying testing with advanced JUnit features, together with the extension model. The extension model allows to extend the Jupiter programming model with custom additions. Thanks to this, third-party frameworks (such as Spring or Mockito, to name a few) can achieve interoperability with JUnit 5 in a seamless way. The extensions provided by these frameworks will be studied in chapter 5, Integration of JUnit 5 with external frameworks. In the current section, we analyze the general performance of the extension model and also the extensions provided out of the box in JUnit 5.

In contrast to former extension points in JUnit 4 (that is, test runners and rules...

This chapter provides an overview of the JUnit 5 testing framework. Due to the limitations of JUnit 4 (monolithic architecture, impossibility of compose test runners, and limitations of test rules), a new major version of the framework was needed. In order to carry out the implementations, the JUnit Lambda project started a crowdfunding campaign in 2015. As a result, the JUnit 5 development team was born, and the GA release of the framework was released on September 10, 2017.

JUnit 5 was designed to be modern (that is, using Java 8 and Java 9 compliant from the very beginning) and modular. The three major components within JUnit 5 are: Jupiter (new programming an extension model), Platform (foundation for any testing framework executed in the JVM), and Vintage (integration with legacy JUnit 3 and 4 tests). At the time of this writing, JUnit 5 tests can be executed...