-
Notifications
You must be signed in to change notification settings - Fork 638
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
Milestone
Comments
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>
I just saw this. Looking.
…On Mon, Jan 17, 2022 at 3:13 AM Sebastian Schuberth < ***@***.***> wrote:
Hmm. The fix for this also seems to make listOf(1, 2, 3) should
containExactly(1, 2, 3) fail. Is this expected?
—
Reply to this email directly, view it on GitHub
<#2746 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMQS2VT2JU3K3LGFKVCMG3DUWPTWNANCNFSM5KQXFENA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
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
Kotest 5.0.3
This is the continuation of this discussion started on the
Kotest
slack communitySummary:
lsh
andrhs
ofshouldBe
forIterable<*>
should recognize, in addition toCollection
and superclasses, also bareboneIterable
implementations.There is ambiguity as to how address type equality.
Presently
shouldBe
makes a special case forSet
, which isCollection
but is not universally guaranteed to be ordered (inKotlin
; Set as large has no ordering guarantee whatsoever). OtherCollection
subclasses in Kotlin are strictly ordered. From the slack thread:The intent is, therefore, to allow
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-SetCollection
I'm preparing a pull request to address the above
The text was updated successfully, but these errors were encountered: