TestNG Version
7.1.0
Expected behavior
assertEquals yields true if called with two sets that contain the same elements, even if they are defined as Collection.
Actual behavior
Depending on the type of set and the type of objects they contain assertEquals might work well or fail because it relies on iterators to compare the two sets and in the case of sets the iteration order is not guaranteed. This behavior is is most evident on LinkedHashSets but also appears on HashSets depending on the type of objects they contain. I suspect it works well with TreeSets, which have a predictable iteration order.
Is the issue reproductible on runner?
Test case sample
Test case excerpt (full test in attachment):
@Test
public void assertEqualsWorksOnLinkedHashSets() {
final Collection<Integer> oneSet = new LinkedHashSet<>();
oneSet.add(1);
oneSet.add(2);
final Collection<Integer> anotherSet = new LinkedHashSet<>();
anotherSet.add(2);
anotherSet.add(1);
assertTrue(oneSet.equals(anotherSet)); //passes
assertEquals(oneSet, anotherSet); //fails
}
AssertEqualsOnSetsTest.zip
TestNG Version
7.1.0
Expected behavior
assertEqualsyields true if called with two sets that contain the same elements, even if they are defined asCollection.Actual behavior
Depending on the type of set and the type of objects they contain
assertEqualsmight work well or fail because it relies on iterators to compare the two sets and in the case of sets the iteration order is not guaranteed. This behavior is is most evident onLinkedHashSets but also appears onHashSets depending on the type of objects they contain. I suspect it works well withTreeSets, which have a predictable iteration order.Is the issue reproductible on runner?
Test case sample
Test case excerpt (full test in attachment):
AssertEqualsOnSetsTest.zip