Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test fails because lhs of shouldBe is List, and rhs is a home-grown Iterable #2746

Closed
Tracked by #2678
inquiribus opened this issue Dec 21, 2021 · 3 comments
Closed
Tracked by #2678
Milestone

Comments

@inquiribus
Copy link
Contributor

Kotest 5.0.3

This is the continuation of this discussion started on the Kotest slack community

Summary: lsh and rhs of shouldBe for Iterable<*> should recognize, in addition to Collection and superclasses, also barebone Iterable implementations.

There is ambiguity as to how address type equality.

Presently shouldBe makes a special case for Set, which is Collection but is not universally guaranteed to be ordered (in Kotlin; Set as large has no ordering guarantee whatsoever). Other Collection subclasses in Kotlin are strictly ordered. From the slack thread:

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) // false

[ neither this should pass ]

listOf(1,2,3) shouldBe setOf(1,2,3)  // false

The intent is, therefore, to allow

myIterable(1,2,3) shouldBe myOtherIterable(1,2,3) // true

to succeed, with as little disruption as possible to the current state of affairs, maintaining backward compatibility at large, but also introducing the privileged treatment for Set which should not test equal to other non-Set Collection

I'm preparing a pull request to address the above

@sschuberth
Copy link
Member

sschuberth commented Jan 17, 2022

Hmm. The fix for this also seems to make listOf(1, 2, 3) should containExactly(1, 2, 3) fail. Is this expected?

Edit: Scratch that, I cannot reproduce this anymore.

sschuberth added a commit to oss-review-toolkit/ort that referenced this issue Jan 17, 2022
In usual sets, the order is undefined / implementation specific. That is
why comparing sets via `containExactly` is fragile, esp. when the
expected collection is not a set of the same type.

Fix this by using a set of the same type as the expected collection or
by ignoring the order.

Also see [1].

[1]: kotest/kotest#2746

Signed-off-by: Sebastian Schuberth <sebastian.schuberth@bosch.io>
sschuberth added a commit to oss-review-toolkit/ort that referenced this issue Jan 17, 2022
In usual sets, the order is undefined / implementation specific. That is
why comparing sets via `containExactly` is fragile, esp. when the
expected collection is not a set of the same type.

Fix this by using a set of the same type as the expected collection or
by ignoring the order.

Also see [1].

[1]: kotest/kotest#2746

Signed-off-by: Sebastian Schuberth <sebastian.schuberth@bosch.io>
sschuberth added a commit to oss-review-toolkit/ort that referenced this issue Jan 17, 2022
In usual sets, the order is undefined / implementation specific. That is
why comparing sets via `containExactly` is fragile, esp. when the
expected collection is not a set of the same type.

Fix this by using a set of the same type as the expected collection or
by ignoring the order.

Also see [1].

[1]: kotest/kotest#2746

Signed-off-by: Sebastian Schuberth <sebastian.schuberth@bosch.io>
@inquiribus
Copy link
Contributor Author

inquiribus commented Jan 18, 2022 via email

@sschuberth
Copy link
Member

Please see my edit, I don't think anymore that there's an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants