some learnings related to migrating to JUnit5.
- JUnit5 has different dependencies, in terms of maven / gradle coordinates. We’re not just talking about bumping a version number. Importantly, the project name ‘Juniper’ is one which you’ll come across regularly with JUnit5.
- JUnit5 requires the maven surefire plugin (and similar for gradle) to use a different test runner from the one packaged as standard. This is a configuration change.
- There’s a JUnit4 compatibility layer to allow seamless migration without code change.
- New-style JUnit5 test can coexist with old-style JUnit4 (vintage) tests in the same codebase.
- Some new IDEA warnings relate specifically to some things about how the new JUnit5 functionality can reduce the amount of boilerplate in your test code.
- The new JUnit5 API exists within a new package – org.junit.juniper.api. Any JUnit5 test should only pull in things from under that package. The old ‘junit.Test’ and ‘org.junit.Test’ annotations only exist for backwards compatibility with JUnit4.
- There are some simple 1-1 differences between old-style and new-style uses.
- @Test is in the new package.
- @Before and @After become @BeforeEach and @AfterEach (+ package change) respectively
- @BeforeClass and @AfterClass become @BeforeAll and @AfterAll respectively
- After that there are some more complex changes required around Rules
- @Rule is replaced by @RegisterExtension. However, JUnit4 Rules cannot *simply* be repurposed as JUnit5 extensions (because they operate on a different API).
- It’s *usually* possible to convert an ‘ExternalResource’ @Rule into an extension by implementing the appropriate interfaces (e.g. BeforeEachCallback, AfterEachCallback)
- With a JUnit5 test methods no longer need to be public.