After the JUnit 5 was released, a lot of developers just added this awesome new library in their projects, because unlike others versions, this new version, is not necessary migrate from JUnit 4 to 5, you just need include the new library in your project, and with all the engine of JUnit 5 you can do your new tests using JUnit 5, and the older one with JUnit 4 or 3, will keep running without problem.
But what can happen in a big project, a project that was builded 10 years ago with two versions of JUnit running in parallel ?
New developers have started to work in the project, some of them with JUnit experience, anothers no. New tests are created using JUnit 5, new tests are created using JUnit 4, at some point a developer without knowlegde, when they will create a new scenario in a JUnit 5 test that has been already created, they just include a JUnit 4 annotation, and the test became a mix, some @Test of JUnit 4 and some @Test of JUnit 5, and each day is more difficult to remove JUnit 4 library.
So, how to solve this problem?
First of all, you need to show to your team, what is from JUnit 5 and what is from JUnit 4, so that new tests be create using JUnit 5 instead of JUnit 4. After that is necessary follow the boy scout rule, whenever they pass by a JUnit 4 test they must migrate to JUnit 5.
Let’s see the mainly changes released in JUnit 5. All starts by the name, in JUnit 5, you don’t see packages called org.junit5, but rather org.junit.jupiter. To sum, everything you see with “jupiter”, it means that is from JUnit 5. They chose this name because Jupiter starts with “JU”, and is the fifth planet from the sun.
Another change is about the @Test , this annotation was moved to a new package : org.junit.jupiter.api and now no one attribute like “expected”, “timeout” is used anymore, use extension instead. For example, for timeout, now you have one annotation for this:
@Timeout(value = 100, unit = TimeUnit.MILLISECONDS) . Another change is that neither test methods nor classes need to be public.
Now instead of use @Before and @After in your test configuration, you have to use @BeforeEach and @AfterEach, and you have also @BeforeAll and @AfterAll .
To ignore tests, now you have to use @Disable instead of @Ignore .
A great news that was released in JUnit 5 was the annotation @ParameterizedTest , with that is possible to run one test multiple times with different arguments. For example, if you want to test a method that create some object and you want validade if the fields are filled correctly, you just do:
There are so nice features in JUnit 5 , I recommend you check it out the JUnit 5 User Guide, to analyze what is useful to your project. https://junit.org/junit5/docs/current/user-guide/
Now that all developers knows what was changed in JUnit 5, you can start the process of removing of JUnit 4 from your project. So, if you are still using JUnit 4 in 2024, and your project is a big project, you will probably have some dependencies using JUnit 4. I recommend you analyze your libraries to check if some of them is using JUnit 4.
In the image bellow I’m using Dependency Analyzer from IntelliJ.
As you can see, jersey-test is using JUnit 4, that is, even if I remove JUnit 4 from my project, JUnit 4 will be available to use because Jersey. The easier way will be bump jersey to 2.35, because JUnit 5 was introduced in jersey-test 2.35, but I can’t update jersey-test framework because other libraries will break in my project. So, in this case, what can I do?
I can exclude JUnit from jersey with Dependency Exclusions from maven(like image bellow). That way JUnit 4 will not be use anymore, but rather our JUnit 5.
After that, when you run some test wich uses Jersey, they will not be loaded, because there are methods in Jersey using JUnit 4 annotations, setUp and tearDown, using @Before and @After . To solve this, you can create one “Configurarion Class” whose extends JerseyTest implementing setUp and tearDown with @BeforeEach and @AfterEach calling super.setUp() and super.TearDown().
So, if you have already checked your libraries and no one has more dependency from JUnit 4, you finally can migrate all your tests to JUnit 5, and for this process, there is a good tool that saves you from a lot of work, is OpenRewrite (https://docs.openrewrite.org/) , a automated refactoring ecosystem for source code, they will change all your old packages, the older annotations, and everything to the new one.
That’s it folks, now you and your team mates can enjoy JUnit 5 and relax your mind knowing that new test’s will be create with JUnit 5 and the project will not became a frankenstein. So, remember, keep your project up-to-date, because if you forget your libraries, each day will be more difficult to update, always use specification, frameworks that follows the specification, and have a good design in your code, this permits you change and move with facility.
