# JUnit 5 migration **URL:** \ **Category:** Logstash\ **Created:** [January 25, 2020, 3:19pm UTC](https://discuss.elastic.co/t/junit-5-migration/216527 "2020-01-25T15:19:07Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![benoitdupont](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/benoitdupont/32/61267_2.png) [@benoitdupont](https://discuss.elastic.co/u/benoitdupont)\ **Post date:** [January 25, 2020, 3:19pm UTC](https://discuss.elastic.co/t/junit-5-migration/216527/1 "2020-01-25T15:19:07Z")
Hello Logstash team, when browsing the Java code I saw that JUnit version 4.12 is still used, instead of the [latest 5.6](https://github.com/junit-team/junit5/releases/tag/r5.6.0). If it's not already on the agenda, here's a proposition of a migration plan: 1. First, update the Gradle dependency from 4 to JUnit 5.6, and add `junit-vintage-engine` on the classpath. By doing this, we decouple the code migration from the dependency migration and could already validate that the tests are still executed correctly (could be by comparing test reports or something in the CI). Note that by including also the platform launcher and the engine, JUnit 5 tests will also be able to run. 2. Migrate one more more classes to JUnit 5, which will serve as reference for the next classes to migrate. The 'pilot' class or classes should have several relevant test features like assertThrows, JUnit rules, ... Here's the [offical JUnit 4 to 5 migration guide](https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4) 3. Update the [CONTRIBUTING.md](https://github.com/elastic/logstash/blob/master/CONTRIBUTING.md) file to request that all new Java tests should use JUnit 5, and the upper class(es) as a reference. Here's [an example](https://github.com/joel-costigliola/assertj-core/blob/master/CONTRIBUTING.md) of how the project AssertJ did it. 4. Migrate whole packages on the side, depending on the selected strategy 5. Cleanup by removing `junit-vintage-engine` dependency when all JUnit4 tests has been migrated Here's my **personal feedback** on this migration, which I already did both as a big bang and incrementally on work projects: The big bang approach works well and is efficient if you're in complete control of the codebase, for instance for internal projects. But for an Open Source codebase, I would choose the incremental option, which is safer and more controlled. This is how the project AssertJ has done this for example and it seems right to me. As for the "why" we should migrate, I'll say the soonest the better, otherwise the test code to migrate will increase with time. The other reasons and interesting features are widely documented on the web, I give some pointers at the end of this post. What do you think ? If interested I'll be happy to create the relevant issues and the PR for the upper migration phases. Cheers, Benoit _Quick links on JUnit 5:_ [https://junit.org/junit5/docs/current/user-guide](https://junit.org/junit5/docs/current/user-guide) > **[Migrating from JUnit 4 to JUnit 5 | Baeldung](https://www.baeldung.com/junit-5-migration)** > > Learn how to migrate from JUnit 4 to the latest JUnit 5 release - with an overview of the differences between the two versions. > **[Why you should migrate to Junit 5](https://medium.com/riag-digital-techblog/why-you-should-migrate-to-junit-5-15438f5c56f)** > > by Michael Altenburger ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [February 22, 2020, 3:19pm UTC](https://discuss.elastic.co/t/junit-5-migration/216527/2 "2020-02-22T15:19:10Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.