truth: int vs long in error messages

I’m sure this isn’t a new issue but I couldn’t find an existing report:

assertThat(ImmutableList.of(1L)).containsExactly(1);

Results in

java.lang.AssertionError: Not true that <[1]> contains exactly <[1]>. It is missing <[1]> and has unexpected items <[1]>

In the situation where the output would be ambiguous, it would be nice if Truth would disambiguate by adding the “L” suffix as necessary.

About this issue

Original URL
State: closed
Created 10 years ago
Reactions: 2
Comments: 18 (11 by maintainers)

Most upvoted comments

Oh, that’s good to know, thanks! (I’m using Truth 0.23).

As far as dealing with the original issue is concerned, I think a sensible scheme for disambiguation could be:

assertThat(ImmutableList.of("1")).containsExactly(1L);
java.lang.AssertionError: Not true that <[1]> contains exactly <[1]>.

It is missing <[1 (java.lang.Long)]>

This could be done by introducing a Disambiguator class that keeps track of the string representations of all the elements. When time comes to emit the differences, the disambiguator is asked to disambiguate each element before it is emitted.

sjamesr on Nov 18, 2014

What if the hashcodes are equal too? !a.equals(b) does not imply a.hashCode() != b.hashCode(). 😃

I would be happy if the basic case of int literals vs longs (and probably float literals vs doubles) worked for collections.

sjamesr on Nov 12, 2014