[ 
https://issues.apache.org/jira/browse/COLLECTIONS-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anirudh Ragavender updated COLLECTIONS-850:
-------------------------------------------
    Description: 
Overview of PR 
This PR proposes a fix for the following tests:
 * 
org.apache.commons.collections4.multimap.TransformedMultiValuedMapTest.testMultiValuedMapIterator
 * 
org.apache.commons.collections4.multimap.ArrayListValuedHashMapTest.testMultiValuedMapIterator

Problem:
In this test, a multivalued map is defined and an iterator is defined on top of 
that. The test is flaky since the order inside the multivalued map is not 
maintained.
Since the order is not maintained, the iterator can have any one key of the 
three keys for this test ( one, two, three) in random fashion. This flakiness 
was identified by the [nondex 
tool|https://github.com/TestingResearchIllinois/NonDex] created by the 
researchers of UIUC.

Fix:

To maintain order, we can implement a TreeMap or a LinkedHashMap but that will 
change the base code and affect all other entities related to this.
This PR proposes a fix inside the test while keeping the test logic intact. 
Since the order is not maintained, we check for the iterator's next value to 
either be one of the keys and if it is, we check the original assert 
statements. We follow the same approach to assert all the cases.

  was:
Overview of PR 
This PR proposes a fix for the following tests:
 * 
org.apache.commons.collections4.multimap.TransformedMultiValuedMapTest.testMultiValuedMapIterator
 * 
org.apache.commons.collections4.multimap.ArrayListValuedHashMapTest.testMultiValuedMapIterator

Problem:
In this test, a multivalued map is defined and an iterator is defined on top of 
that. The test is flaky since the order inside the multivalued map is not 
maintained.
Since the order is not maintained, the iterator can have any one key of the 
three keys for this test ( one, two, three) in random fashion. This flakiness 
was identified by the [nondex 
tool|https://github.com/TestingResearchIllinois/NonDex] created by the 
researchers of UIUC.

Fix:

To maintain order, we can implement a TreeMap or a LinkedHashMap but that will 
change the base code and affect all other entities related to this.
This PR proposes a fix inside the test while keeping the test logic intact. 
Since the order is not maintained, we check for the iterator's next value to 
either be one of the keys and if it is, we check the original assert 
statements. We follow the same approach to assert all the cases.
 
{{{}{}}}{{{}{}}}{{{}{}}}{{{}{}}}


> testMultiValuedMapIterator is non-deterministic
> -----------------------------------------------
>
>                 Key: COLLECTIONS-850
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-850
>             Project: Commons Collections
>          Issue Type: Bug
>          Components: Map
>    Affects Versions: 4.4
>            Reporter: Anirudh Ragavender
>            Priority: Minor
>             Fix For: 4.5
>
>
> Overview of PR 
> This PR proposes a fix for the following tests:
>  * 
> org.apache.commons.collections4.multimap.TransformedMultiValuedMapTest.testMultiValuedMapIterator
>  * 
> org.apache.commons.collections4.multimap.ArrayListValuedHashMapTest.testMultiValuedMapIterator
> Problem:
> In this test, a multivalued map is defined and an iterator is defined on top 
> of that. The test is flaky since the order inside the multivalued map is not 
> maintained.
> Since the order is not maintained, the iterator can have any one key of the 
> three keys for this test ( one, two, three) in random fashion. This flakiness 
> was identified by the [nondex 
> tool|https://github.com/TestingResearchIllinois/NonDex] created by the 
> researchers of UIUC.
> Fix:
> To maintain order, we can implement a TreeMap or a LinkedHashMap but that 
> will change the base code and affect all other entities related to this.
> This PR proposes a fix inside the test while keeping the test logic intact. 
> Since the order is not maintained, we check for the iterator's next value to 
> either be one of the keys and if it is, we check the original assert 
> statements. We follow the same approach to assert all the cases.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to