assertThat((Comparable) obj) not working

I have a class (PowerClass in examples below) which is Iterable and Comparable. I was trying to test it with something similar like the example below.

// assertThat(new PowerClass()).isEqualTo(new PowerClass()); // Ambiguous method call.
assertThat((Object) new PowerClass()).isEqualTo(new PowerClass()); // does not look nice
assertThatObject((Object) new PowerClass()).isEqualTo(new PowerClass()); // better way of line above
assertThat((Iterable<PowerClass>) new PowerClass()).contains(new PowerClass()); // looks not nice but works
// assertThat((Comparable<PowerClass>) new PowerClass()).isGreaterThan(new PowerClass()); // counts as Object not Comparable

It works only like expected if the class is only Iterable and no cast is present.

assertThat(new PowerClass()).isGreaterThan(new PowerClass());

It would be nice if the cast would work, and to prevent ambiguous method calls to have own assertThat calls for Iterable and Comparable like assertThatObject. (ref. #1388) The other solution would be to call the GenericComparableAssert constructor on our own (or create a method for that).

This may also affect other interfaces (like Throwable?).

[joel-costigliola]

pros and cons of having assertThat[InterfaceName] in AssertionsForInterfaceTypes:

• pros: easy to discover
• cons: quite a lot of new methods in AssertionsForInterfaceTypes and co (BDDAssertions, WithAssertions, …)

pros and cons of having assertThat[InterfaceName] in [InterfaceName]Assert is basically the opposite.

maybe we can find a middle ground where we would add assertThat[InterfaceName] in AssertionsForInterfaceTypes for commonly implemented interfaces like Comparable.

We’ll discuss it with the team before moving forward.

[rala72]

note that one will not be able to static import every potentially ambiguous assertThat

what about the first suggestion of adding assert[InterfaceName]? these methods don’t have to be added in AssertionsForClassTypes / AssertionsForInterfaceTypes if you want to prevent it from having too many methods; it is also fine in each Interface implementation like GenericComparableAssert like that, we can still import the methods statically (you can do these also additionally to the other plan you presented above)