Explore how to deal with all versions from JUnit and how to organize your tests in your project to bring more productivity to your team.
After JUnit 5 was released, a lot of developers just added this awesome new library to their projects, because unlike other versions, in this new version, it is not necessary to migrate from JUnit 4 to 5, you just need to 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 built 10 years ago with two versions of JUnit running in parallel?
New developers have started to work on the project, some of them with JUnit experience, others not. New tests are created using JUnit 5, new tests are created using JUnit 4, and at some point a developer without knowledge, 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 the JUnit 4 library.
So, how do you 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 created using JUnit 5 instead of JUnit 4. After that is necessary to follow the Boy Scout rule, whenever they pass a JUnit 4 test they must migrate to JUnit 5.
Let’s see the main 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 up, everything you see with “Jupiter”, it means that is from JUnit 5.
