JSON-java
JSON-java copied to clipboard
Migrating to Junit 5
I tried to upgraded the code base to Junit 5 to get new features for unit testing. Below are the steps, I followed :
Steps:
- Upgrading dependencies in maven and gradle
- Changing Packages
- org.junit.Test to org.junit.jupiter.api.Test
- org.junit.Assert.* to org.junit.jupiter.api.Assertions.*
- Junit 4(message,value) Parameter changes to Junit 5 (value ,message ).
- Better Exception Handling. (https://www.baeldung.com/junit-assert-exception)
- @Rule and @ClassRule in JUnit 4 should be done with @ExtendWith and Extension
- @Ignore to @Disabled https://www.softwaretestinghelp.com/junit-ignore-test-cases/
- @RunsWith Parameterized should be done with @ExtendWith (https://www.baeldung.com/parameterized-tests-junit-5)
@anudeepikamunnangi Thanks for opening the issue. Is there some compelling reason to upgrade to Junit 5 at this time?
@stleary, Thanks for reviewing the PR and the issue.
Before i go with advantages, i would like to confirm that, i did not change any test case logic. All i did is to make it work in JUNIT 5 way of writing the same test cases.
Recently, in our automation team, we migrated our legacy applications from JUNIT 4 to JUNIT 5. We observed that there are below advantages.
JUnit 5 Advantages
Let’s start with the previous version, JUnit 4 , which has some clear limitations:
- A single jar library contains the entire framework. We need to import the whole library, even when we only require a particular feature. In JUnit 5, we get more granularity and can import only what’s necessary.
- Only one test runner can execute tests at a time in JUnit 4 (e.g. SpringJUnit4ClassRunner or Parameterized ). JUnit 5 allows multiple runners to work simultaneously.
- JUnit 4 never advanced beyond Java 7, missing out on a lot of features from Java 8. JUnit 5 makes good use of the Java 8 features.
The idea behind JUnit 5 was to completely rewrite JUnit 4 in order to negate most of these drawbacks.
References
- https://www.baeldung.com/junit-assert-exception
- https://www.baeldung.com/parameterized-tests-junit-5
- https://www.softwaretestinghelp.com/junit-ignore-test-cases/
- https://www.baeldung.com/junit-5-migration
Thanks for the response. No objection to using Junit 5, but small steps are preferred over mass changes. Recommend just upgrading the version for now, but keeping the existing tests. I think Junit 5 has a library to support that.
I'm happy if JUnit 5 is adopted I really like the new version.
Keep in mind that JUnit 5 has a few differences from JUnit 4, which means lots of syntax changes on the test package.
- A different API structure
- Assertion message position is different
- Annotations for running code before and after each method or class
Example
JUnit 4
org.junit.Assert.assertTrue
JUnit 5
org.junit.jupiter.api.Assertions.assertTrue
@rikkarth "Thanks for highlighting the differences. I've ensured code adheres to JUnit5 standards, including the changes you mentioned."
In relation to the closed PR https://github.com/stleary/JSON-java/pull/848 I want to clarify that it is not possible to upgrade to JUnit 5 without lots of syntax changes, therefor this will inevitably be a big effort.
Parameterized dependency and test are not mandatory if you want to keep the upgrade and PR smaller and easier to review in a first stage.
Alternatively we can use JUnit vintage (provided by JUnit team) which is an engine which provides backwards compatibility with Junit 3 and 4, JUnit vintage is used specially for cases like this, migrations.
This would mean, that if we perform the upgrade like I'm suggesting we are able to produce small, focused PRs that are easier to digest, review and test without breaking anything and maintaining existing functionality.
I've used it professionally in the past to upgrade JUnit from 4 to 5.
I recommend a new branch from master and a new PR.
https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4 (official) https://www.baeldung.com/java-junit-vintage-engine-vs-junit-jupiter-engine
cc @stleary
Closing due to the amount of effort to upgrade vs actual benefit of migrating to JUnit5.