Unexpected Behaviour: assertEquals for Iterable

assertEquals( Iterable a, Iterable b ) usses it's own equals implementation and ignores existing equals methods.

Consider something like: (no real java code, I know)

class MyClass implements Iterable<MyPart> {
    private int myValue;
    public boolean equals( Object o ){
        return myValue == o.myValue && super.equals( o );
    }
}

assertEquals( myClass1, myClass2 ) now doesn't take myValue into account because it doesn't use the equals method but it's own implementation of that so it will report some objects as equal even if they aren't.

So in order to compare some objects which implement Iterable you have to use assertTrue( myClass1.equals( myClass2 ) ) (which will fail misserably if myClass1 is null) or assertEquals( (Object) myClass1, (Object) myClass2 )

I think this is neither obvious nor does the documentation help much because I think nearly noone will read every single documentation for assertEquals in case it does something unexpected.

In contrast e.g. AssertJ's assertThat( myClass1 ).isEqualTo( myClass2 ) uses equals method on Iterable, too.

The sensible thing to do would be to use the objects equals method even for Iterable (which does compare the content in the right way, anyway) and only if this fails use some means of inspection to report which part did fail.

Start by locating the assertEquals(Iterable, Iterable) overload described in the issue and inspect how it compares values. Reproduce the example with Iterable objects that define equals, including null cases, then verify that the comparison honors equals and still reports useful differences without breaking existing assertions.