stleary / JSON-java

A reference implementation of a JSON package in Java.
http://stleary.github.io/JSON-java/index.html
Other
4.49k stars 2.55k forks source link

Migrating to Junit 5 #847

Open anudeepikamunnangi opened 6 months ago

anudeepikamunnangi commented 6 months ago

I tried to upgraded the code base to Junit 5 to get new features for unit testing. Below are the steps, I followed :

Steps:

  1. Upgrading dependencies in maven and gradle
  2. Changing Packages
    1. org.junit.Test to org.junit.jupiter.api.Test
    2. org.junit.Assert. to org.junit.jupiter.api.Assertions.
  3. Junit 4(message,value) Parameter changes to Junit 5 (value ,message ).
  4. Better Exception Handling. (https://www.baeldung.com/junit-assert-exception)
  5. @Rule and @ClassRule in JUnit 4 should be done with @ExtendWith and Extension
  6. @Ignore to @Disabled https://www.softwaretestinghelp.com/junit-ignore-test-cases/
  7. @RunsWith Parameterized should be done with @ExtendWith (https://www.baeldung.com/parameterized-tests-junit-5)
anudeepikamunnangi commented 6 months ago
issue

while, I was running testcase in debug mode in my local with Java11. This testcase recursiveDepthArrayFor1000Levels is passing.

stleary commented 6 months ago

@anudeepikamunnangi Thanks for opening the issue. Is there some compelling reason to upgrade to Junit 5 at this time?

anudeepikamunnangi commented 6 months ago

@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:

  1. 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.
  2. 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.
  3. 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

  4. https://www.baeldung.com/junit-assert-exception
  5. https://www.baeldung.com/parameterized-tests-junit-5
  6. https://www.softwaretestinghelp.com/junit-ignore-test-cases/
  7. https://www.baeldung.com/junit-5-migration
stleary commented 6 months ago

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.

rikkarth commented 4 months ago

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.

Example

JUnit 4

org.junit.Assert.assertTrue

JUnit 5

org.junit.jupiter.api.Assertions.assertTrue

anudeepikamunnangi commented 4 months ago

@rikkarth "Thanks for highlighting the differences. I've ensured code adheres to JUnit5 standards, including the changes you mentioned."

rikkarth commented 2 months ago

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