stleary / JSON-java

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

Fixed flaky tests in XMLTest.java #828

Closed harshith2000 closed 1 year ago

harshith2000 commented 1 year ago

Issue: The shouldCreateExplicitEndTagWithEmptyValueWhenConfigured test and the shouldNotCreateExplicitEndTagWithEmptyValueWhenNotConfigured test in XMLTest.java fails due to an assertCheck between two XML Strings.

https://github.com/stleary/JSON-java/blob/11c29c366de87fc3be38d26f2f0dac96ce28312e/src/test/java/org/json/junit/XMLTest.java#L1187 https://github.com/stleary/JSON-java/blob/11c29c366de87fc3be38d26f2f0dac96ce28312e/src/test/java/org/json/junit/XMLTest.java#L1196

The toString function of the Object class makes no guarantees as to the iteration order of the attributes in the object. This makes the test outcome non-deterministic and the test fails whenever the toString changes the order of the properties. To fix this, the expected and actual values should be checked in a more deterministic way so that the assertions do not fail.

Fix Expected and Actual values can be converted into JSONObject and the similar can be used to compare these objects. As this function compares the values inside the JSONObjects without needing order, the test becomes deterministic and ensures that the flakiness from the test is removed.

To reproduce:

I utilized the open-source tool NonDex to detect this assumption by altering the order of returned exception types.

To replicate:

Clone the Repository:

git clone https://github.com/stleary/JSON-java.git

Integrate NonDex:

Add the following snippet to the top of the build.gradle file:

plugins {
    id 'edu.illinois.nondex' version '2.1.1-1'
}

Add to the end of the build.gradle file:

apply plugin: 'edu.illinois.nondex'

Execute Test with Gradle:

./gradlew --info test --tests path.to.the.TestClass.testMethod

Run NonDex:

./gradlew --info nondexTest --tests=path.to.the.TestClass.testMethod --nondexRuns=X

The PR does not introduce a breaking change.

stleary commented 1 year ago

What problem does this code solve? Fixes a couple of potential errors due to object ordering in the unit tests

Does the code still compile with Java6? Yes

Risks Low

Changes to the API? N/A

Will this require a new release? No

Should the documentation be updated? No

Does it break the unit tests? No

Was any code refactored in this commit? No

Review status

APPROVED

Starting 3-day comment window