Fixed LocalEventProcessorsAdminServiceTest.testGetByComponent #689
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.
This pull request addresses the flakiness in the
LocalEventProcessorsAdminServiceTest.testGetByComponent
test by resolving the non-deterministic behavior identified using the NonDex tool. The root cause of the flakiness was the non-deterministic order of elements inclients
Flux. The test can be found here.How was the non-deterministic behavior identified in the test?
The non-deterministic behavior in the test was identified by using an open-source research tool named NonDex which is responsible for finding and diagnosing non-deterministic runtime exceptions in Java programs.
Why does the test fail?
The test fails because the actual order of elements emitted by the clients Flux does not match the expected order specified in the expectNext assertion. This assertion expects the elements to be emitted in the order "Client-A", "Client-B", "Client-E." However, the actual order of elements emitted might not be guaranteed.
How I fixed the test?
I fixed the test by using
clients.collectList()
to collect all emitted elements into a list. After collecting the elements into a list,Collections.sort(sortedClients)
is used to sort the list. Sorting the list is important because the test is no longer enforcing a specific order of elements; instead, it is interested in their presence. The verification step usesconsumeNextWith
, which allows you to consume the collected list (sortedClients
) and perform assertions on it. In this case, it ensures that the sorted list of clients matches the expected list.Assertions.assertEquals(Arrays.asList("Client-A", "Client-B", "Client-E"), sortedClients)
checks that the sorted list contains exactly the expected elements, irrespective of their order.Output from NonDex:
You can run the following command to run the test using the NonDex tool:
Test Environment:
Let me know if this fix is acceptable
Thank you!