Fix flaky test through set comparison

[ZhanwangZhou]

Description

I encountered non-deterministic behavior while running the following tests using NonDex:

org.glassfish.jersey.inject.weld.internal.managed.DisposableSupplierTest.testDisposeComposedObjectWithPerLookupFields

Steps to reproduce

NonDex: https://github.com/TestingResearchIllinois/NonDex
Run the tests with NonDex:

mvn -pl incubator/cdi-inject-weld edu.illinois:nondex-maven-plugin:2.1.7:nondex -Dtest=org.glassfish.jersey.inject.weld.internal.managed.DisposableSupplierTest#testDisposeComposedObjectWithPerLookupFields

The error message shows:

Click to view

[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.618 s <<< FAILURE! -- in org.glassfish.jersey.inject.weld.internal.managed.DisposableSupplierTest
[ERROR] org.glassfish.jersey.inject.weld.internal.managed.DisposableSupplierTest.testDisposeComposedObjectWithPerLookupFields -- Time elapsed: 0.061 s <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <1> but was: <3>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)
	at org.glassfish.jersey.inject.weld.internal.managed.DisposableSupplierTest.lambda$testDisposeComposedObjectWithPerLookupFields$5(DisposableSupplierTest.java:371)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:288)
	at org.glassfish.jersey.inject.weld.internal.managed.DisposableSupplierTest.testDisposeComposedObjectWithPerLookupFields(DisposableSupplierTest.java:363)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at java.base/java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:189)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)

[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   DisposableSupplierTest.testDisposeComposedObjectWithPerLookupFields:363->lambda$testDisposeComposedObjectWithPerLookupFields$5:371 expected: <1> but was: <3>
[INFO]
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0

Proposed Solution

The test is flaky because the order of the strings generated from ComposedObject instance is not deterministic. To fix this, instead of comparing the strings one by one, we create a set of the returned strings and a set of expected values. Then, we assertEquals two set to make sure the instance generates all the strings expected while not influenced by the non-deterministic order of the returning strings.

[jansupol]

Hello, please see Missing-ECA,-Missing-Sign-off-by