I have a test that fails because the lhs of

shouldBe

is a

List

, and the rhs is a home-grown

Iterable

. This happens in

IterablEq.kt

(kotest 5.0.3) as

fun isValidIterable(it: Any): Boolean {
      return when (it) {
         is List<*>, is Set<*>, is Array<*>, is Collection<*> -> true
         else -> false
      }
   }

Could someone please help me understand why a custom implementation of

Iterable

should not be considered a valid iterable for the purposes of

kotest

?

Just missed case? Seems valuable to me

Yeah we should add that - PR welcome @Asq

While we're in there, do we have a similar assertion for sequence? Maybe flow?

should include whatever is feasible whilst bearing in mind that you might not want this to pass:

listOf(1,2,3) shouldBe myIterable(1,2,3)

Agree 👌

Respecting types is a sticky issue with iterable collections. The contract of

equals

(same hashcode) is a squishy thing to enforce, especially under inheritance.

shouldBe

as it is at present is largely ambiguous, as it tries really really hard to make things work. Is it trying too hard?

I suppose you could chain should be same type and should iterate equals

@sam I'm preparing a PR