Fix non-idempotent unit test ClassGeneratorTest.testMain
#14135
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #14134.
The Problem
The
ClassGeneratorTest.testMain
test is non-idempotent and fails upon repeated execution within the same JVM instance due to self-induced state pollution. Specifically, the test employs theClassGenerator
to configure a custom class with a predetermined name (Bean.class.getName() + "$Builder"
). Subsequently, the test invokesClassGenerator.toClass()
to instantiate the desiredClass<?>
object. However, withinClassGenerator.toClass()
, the invoked methodjavassist.ClassPool.makeClass()
is called to create the class. Given that Javassist freezes a class upon its initial loading (ensuring classes cannot be altered or removed at runtime), repeated invocations oftestMain()
fail as the class name remains unchanged, leading to class generation errors.Sample Failure Message (in the 2nd run of the test):
What is the purpose of the change
Fixing this issue is recommended since unit tests should be idempotent (deterministically passing in repeated runs).
Brief changelog
Assign a unique ID to each class to be generated in the same classloader.
Verifying this change
After the patch, running the test multiple times within the same JVM will not lead to failures.
Additional Notes
There are some other non-idempotent tests detected in the test suite. I can open a new PR to address the others if you find this fix reasonable.
Checklist