FarmersWrap opened a new pull request, #427: URL: https://github.com/apache/commons-collections/pull/427
# What changes were proposed in this pull request? I found the flaky behavior in src/test/java/org/apache/commons/collections4/multimap/AbstractMultiValuedMapTest.java with an open-source research tool [NonDex](https://github.com/TestingResearchIllinois/NonDex), which will shuffle implementation-dependent operations. The nondex tool detected there is flaky test on line 708. The test is flaky because the original code used twice the toString function. The order of the MultiValueMap is non-deterministic. ``` "{A=[X, Y, Z], B=[U, V, W]}".equals(map.toString()) || "{B=[U, V, W], A=[X, Y, Z]}".equals(map.toString()) ``` It may result in the following comparison, which will make the test fail ``` "{A=[X, Y, Z], B=[U, V, W]}".equals("{B=[U, V, W], A=[X, Y, Z]}") || "{B=[U, V, W], A=[X, Y, Z]}".equals("{A=[X, Y, Z], B=[U, V, W]}") ``` To avoid the the above situation, I used a variable to store the result of the function toString, only one toString result will be generated to compare with the two possible results. Therefore, the flaky bug is fixed ``` String mapString = map.toString(); assertTrue( "{A=[X, Y, Z], B=[U, V, W]}".equals(mapString) || "{B=[U, V, W], A=[X, Y, Z]}".equals(mapString) ); ``` I fixed this test by creating the compared string once and using the only output to compare with those two possible strings. Then, the test will not be flaky. # Does this PR introduce any user-facing change? No # Is the change a dependency upgrade? No # How was this patch tested? Test Environment: ``` openjdk version "11.0.20.1" Apache Maven 3.6.3 Ubuntu 20.04.6 LTS Linux version: 5.4.0-163-generic ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
