Closed yogurtearl closed 9 months ago
The types can also be the same but have failing equality and matching string representation, so you still need something which highlights this fact.
Also, bonus points for:
Truth has all these and it's a great thing to copy.
Perhaps the best solution would be to just explicitly call out that the two objects are different but have the same toString
result in the error message? Maybe something like:
class Example {
override fun toString() = "hello"
}
assertThat(Example()).isEqualTo(Example())
// AssertionFailedError: expected (type: `Example`) and actual (type: `Example`) are not equal but have the same string representation: "hello"
I'm not sure of the best way to refer to each object there.
Another case where calling out the behavior is important is when equals
is broken or identity-based on two otherwise-equivalent types. This will produce two equal outputs and the type of the two is the same. So it perhaps only behooves us to include the type when relevant, otherwise simply noting equals
returned false but toString()
s match.
Another real world example: JDK 20 (well, the CLDR update in it) changed formatting to use a narrow non-break space from a regular space. Very hard to catch until IntelliJ saved me https://jakewharton.com/@jw/111403629212976596
The original issue should be fixed, @JakeWharton feel free to file new issues for any of the other improvements you suggested
Consider:
This correctly fails, but the error message can be a bit confusing.
as of
0.25
, the error message is:A couple of thoughts.
CharSequence
not justString
. so thatAnnotatedString
would print as"asdf"
(with quotes)toString()
result is the same, but they are not equal?