JUnit 5 – New Architecture, New Features
-
Share:
-
-
-
Abstract: JUnit is a unit testing framework for the Java programming language. The JUnit 5 version has been redesigned to solve some particular problems of the previous versions. It comes with a new architecture, with the possibility of creating a hierarchy of nested tests, with new assertions and assumptions capabilities, with dynamic and parameterized tests.
The article would like to be a short introduction to JUnit 5, to provide the reader the possibility to understand the new architecture and new capabilities and to be able to explore further.
1. What is JUnit? What is TDD?
JUnit, as unit testing framework for the Java programming language, is a very important tool for the test-driven development approach. It is part of a family of unit testing frameworks, collectively known as xUnit, originated with SUnit.
JUnit is linked as a JAR at compile-time and the most commonly included external library in Java projects.
TDD (Test Driven Development) is a software development process that relies on the repetition of a very short development cycle: First, requirements are turned into specific test cases; then, the software is improved to pass the new tests, only.
This is opposed to software development that allows software to be added that is not proven to meet requirements.
TDD benefits include:
- The programmer is driven by clear goals
- The code is safer
- Incorrect code can be isolated
- New functionality can be easily introduced
- Tests document the application
The tests pyramid looks this way:
with the focus of our discussion at the level of unit tests. In a real-life scenario, the developer may be in charge with unit testing, component testing, integration testing, behavior driven testing.
2. JUnit 4 shortcomings
The JUnit 4, as released in 2006, provided a simple and monolithic architecture.
All its functionality is concentrated inside a single JAR file. Despite its apparent simplicity, this has generated a series of problems that were stronger and stronger as the time was passing.
The fact that the provided API was not flexible made the IDE and tools that were using JUnit tightly coupled to it. These tools needed to go into the internals of the JUnit classes and even use reflection in order to get the needed information.
So, as the same single JAR was used by everyone and all tools and IDEs were so tightly coupled to it, the possibilities of evolution of JUnit have been seriously reduced. Changing any private variable or method could have broken the ones using it. A new API, designed for such kind of tools, and a new architecture resulted as necessary future improvement.
3.The new modular approach
A new approach, a modular one was necessary in order to allow the evolution of the JUnit. The logical separation of concerns required:
- An API to write tests, dedicated mainly to the developers
- A mechanism for discovering and running the tests
- And 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 3 modules:
JUnit Platform, which serves as a foundation for launching testing frameworks on the JVM. It also provides an API to launch tests from either the console, IDEs, or build tools.
JUnit Jupiter is 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 5th planet of our Solar System, which is also the largest one.
JUnit Vintage provides a test engine for running JUnit 3 and JUnit 4 based tests on the platform, ensuring the necessary backwards compatibility.
Tudose, Florin-Catalin Tudose
