Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed non-idempotent unit tests in JSONObjectTest #889

Merged
merged 1 commit into from May 3, 2024

Conversation

kaiyaok2
Copy link
Contributor

Motivation:

A couple of tests in JSONObjectTest are not idempotent and fail in the second runs in the same JVM, because they pollute states reused by themselves. Specifically, these tests first assume that SingletonEnum.getInstance() or Singleton.getInstance() are in a clean state, and then modify them. However, these instances are not cleaned up after the tests, so the repeated runs fail in the initial sanity check. It shall be good to clean the state pollution so that potential newly introduced tests do not fail in the future due to the shared state polluted by these tests.

Two non-idempotent tests are:

  • testSingletonEnumBean()
  • testSingletonBean()

Error messages for both failed tests in the second run:

java.lang.AssertionError: [someString, someInt] expected:<1> but was:<2>

Proposed Fix

Add a tearDown() method to restore the instances of SingletonEnum and Singleton to default states.

@stleary
Copy link
Owner

stleary commented Apr 26, 2024

@kaiyaok2 Looks reasonable. How did you come across this issue?

@kaiyaok2
Copy link
Contributor Author

@kaiyaok2 Looks reasonable. How did you come across this issue?

@stleary The issue is reported by our custom JUnit runner that supports rerunning test suite in the same JVM (different from Surefire where a new JVM is booted for each mvn test cycle)

@stleary
Copy link
Owner

stleary commented Apr 26, 2024

What problem does this code solve?
Unit tests failing when executed twice in succession in the same JVM

Does the code still compile with Java6?
Yes

Risks
Low

Changes to the API?
No

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

@stleary stleary merged commit 054786e into stleary:master May 3, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants