I have a test that fails because the lhs of `shouldBe` is a `List`, and the rhs is a home-grown `Ite...

# kotest

[Asq]

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 ?

[Jim]

Just missed case? Seems valuable to me

[sam]

Yeah we should add that - PR welcome @Asq

[Jim]

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

[sam]

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)

[sam]

or listOf(1,2,3) shouldBe setOf(1,2,3)

[sam]

I'd be inclined to say shouldBe should fail for those, and you use shouldContainExactly or whatever

[sam]

shouldIterateEquals

[Jim]

Agree 👌

[Asq]

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?

[Jim]

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

[Asq]

@sam I'm preparing a PR

[Asq]

PR at https://github.com/kotest/kotest/pull/2749

[Asq]

issue at https://github.com/kotest/kotest/issues/2746