JUnit 5 essentials
Lifecycle, assertions, parameterized tests, and names that explain the failure.
JUnit 5 in Practice
A test that fails with expected: <true> but was: <false> in a method called testCalcul2 costs you fifteen minutes: you have to open the file, reread the setup, and reconstruct the author's intent. The same test, named un_retrait_superieur_au_solde_est_refuse and ending with an AssertJ assertion that prints the full object, costs you five seconds. The difference is not cosmetic. It determines whether your suite is a diagnostic tool or an alarm with no context.
JUnit 5 is not an incremental version of JUnit 4: it is a rewrite, with a new package (org.junit.jupiter), a new extension model, and an explicit lifecycle. The most common confusion comes from this: org.junit.Test and org.junit.jupiter.api.Test often coexist in the same project, and a class annotated with the old one is simply ignored by the new engine. It doesn't break, it disappears. Always check the number of tests executed after a migration.
Setup
With Maven, a single dependency is enough; recent versions of surefire detect JUnit 5 without any configuration.
<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<version>5.11.3</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.assertj</groupId>
<artifactId>assertj-core</artifactId>
<version>3.26.3</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.5.2</version>
</plugin>
</plugins>
</build>
Comments
Comments are powered by GitHub Discussions
Sign in with GitHub to join the discussion