Truth has a puzzlers section that includes some cases where assertions can be confusing. There's a few of these where assertk falls into the same trap and can be improved.
problem: isSameAs/isNotSameAs naming is not quite clear enough that it uses reference equality
example:
solution:
follow truth and rename to containsAtLeast
problem: numbers of different types never compare equal
example:
assertThat(s.toShort()).isEqualTo(parsedValues.get(s))
// -> expected:<1[]> but was:<1[]>
solution:
I'm a little hesitant to follow truth here and treat byte/short/int/long the same for equality comparisons because it strays from the kotlin equality behavior where 1 == 1.toShort() would fail to compile. It's also somewhat improved by kotlin's smart literal types because
assertThat(1.toShort()).isEqualTo(1)
will treat the second 1 as a short. We can improve the error message through to mark that they are different types.
JakeWharton
commented
9 months ago
Truth has a puzzlers section that includes some cases where assertions can be confusing. There's a few of these where assertk falls into the same trap and can be improved.
problem:
isSameAs/isNotSameAsnaming is not quite clear enough that it uses reference equality example:solution: follow truth and rename to
isSameInstanceAs/isNotSameInstanceAsproblem:
containsAllis ambiguous on what it's actually comparing example:solution: follow truth and rename to
containsAtLeastproblem: numbers of different types never compare equal example:
solution: I'm a little hesitant to follow truth here and treat byte/short/int/long the same for equality comparisons because it strays from the kotlin equality behavior where
1 == 1.toShort()would fail to compile. It's also somewhat improved by kotlin's smart literal types becausewill treat the second 1 as a short. We can improve the error message through to mark that they are different types.