Invert equality check?

[shmosel]

When comparing abstractions (e.g. Map) via assertEquals(expected, actual), it's more likely that actual is a custom class. If there's a bug in the equals() implementation, it could be caught by calling actual.equals(expected) instead of the inverse.

For example, here's an implementation of Map.Entry that violates the equals() contract:

class EmptyEntry<K, V> implements Map.Entry<K, V> {
    @Override public K getKey() { return null; }
    @Override public V getValue() { return null; }
    @Override public V setValue(V value) { return null; }
}

This assertion passes:

assertEquals(new AbstractMap.SimpleEntry<>(null, null), new EmptyEntry<>());

This assertion fails:

assertEquals(new EmptyEntry<>(), new AbstractMap.SimpleEntry<>(null, null));

Shouldn't it work the other way?

[marcphilipp]

it's more likely that actual is a custom class.

I'm not convinced that's generally the case.

I guess assertEquals() could check both actual.equals(expected) and expected.equals(actual) but that's unnecessary in most cases.

How about a new assertion that does so instead, e.g. assertEqualsSymmetrically()?

[jbduncan]

@shmosel Please correct me if I'm wrong, but it sounds like you're after an assertion that checks that EmptyEntry.equals() has been implemented correctly.

If so, then I think having an assertion that works similarly to EqualsTester from guava-testlib, or EqualsVerifier would be a better option. This would allow all edge cases of a good equals() implementation to be tested properly, like ensuring that equals(null) == false.

[shmosel]

Realizing what needs to be checked is half the battle. I actually wrote a test like this and forgot it was necessary to implement equals(). Wouldn't it be better if we could catch a mistake like that for free?

[jbduncan]

@shmosel Indeed! Though my gut feeling is incorporating this check into e.g. every call to assertEquals would slow down large test suites too much, but I'll leave that to the JUnit maintainers to decide and profile. :)

[marcphilipp]

Team decision: The goal of assertEquals() in Jupiter is general-purpose, analogous to Objects.equals(). If you wish to check both directions, you can invoke assertEquals(a, b) and assertEquals(b, a) (same as with Objects.equals) and extract that into your own assertion method for reuse.

The same applies to verification of the contract of equals() and hashCode(). As mentioned in #3120 (comment) there are dedicated libraries that already address that use case.