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.
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
isSameInstanceAs
/isNotSameInstanceAs
problem:
containsAll
is ambiguous on what it's actually comparing example:solution: follow truth and rename to
containsAtLeast
problem: 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.