Collection assertions

[Kantis]

Highlights:

• Deprecates shouldExist in favor of forAny
• Adds forSingle inspector, that asserts that a collection has a single element, which matches the assertion
• Adds lambda-based alternatives to predicate-based existInOrder matcher
  • matchEach 1:1 match element:assertion
  • matchInOrder assert in order, with no gaps
  • matchInOrderSubset assert in order, gaps allowed

[Kantis]

Any feedback on the naming of existInAssertedOrder()?

I would ideally have liked to use existInOrder(assertions: List<(T) -> Unit>) for this one as well, but it seemed to clash with the existing existInOrder(ps: List<(T) -> Boolean>)

[sksamuel]

I don't like the name existInAssertedOrder.
Perhaps shouldAssertInOrder but we need one that works with gaps and one that doesn't.

shouldAssertSubset <- gaps ?
shouldAssert <- no gaps ?

[Kantis]

shouldAssert means the matcher would be named assert? I think that might be confusing?

Maybe shouldFullyMatch, shouldPartiallyMatch? 🤔

I agree it would be nice to offer both a complete match opportunity, and a subset match.. Perhaps it would also be nice to be able to specify if they shouold exist in order or not..

[sksamuel]

shouldPassEach shouldApplyInOrder shouldAssertEach

…

On Tue, 30 Nov 2021 at 13:12, Emil Kantis ***@***.***> wrote: shouldAssert means the matcher would be named assert? I think that might be confusing? Maybe shouldFullyMatch, shouldPartiallyMatch? 🤔 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2695 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVSGU57C6LJW63VH36DQ3UOUOY5ANCNFSM5JACH4QQ> . 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>.

[Kantis]

shouldMatchInOrder - Test vararg of assertions against collection, does not require exhaustive test
shouldMatchInOrderWithoutGaps - same as above, disallowing gaps
shouldMatchAll - same as above, but must be exhaustive for the list. E..g assertion 1 must pass element 1, and one assertion must exist for each element

Matchers would then be matchAll and matchInOrder, latter taking a parameter to decide whether gaps are allowed.

Do you prefer another verb?

[sksamuel]

I think those names should good, and maybe shouldMatchInOrderWithoutGaps could be shouldMatchInOrderSubset

[sksamuel]

@Kantis can you rebase whenever you're able :)

[sksamuel]

@Kantis do you have time to finish this up for 5.1 release this week?
If not I can move to 5.2

[Kantis]

@Kantis do you have time to finish this up for 5.1 release this week? If not I can move to 5.2

I'll try ✌🏼 Sorry for not responding for a while, I mentally checked out over the holidays

[sksamuel]

So did I. Was wonderful :)

…

On Wed, 12 Jan 2022 at 08:06, Emil Kantis ***@***.***> wrote: @Kantis <https://github.com/Kantis> do you have time to finish this up for 5.1 release this week? If not I can move to 5.2 I'll try ✌🏼 Sorry for not responding for a while, I mentally checked out over the holidays — Reply to this email directly, view it on GitHub <#2695 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVSGWA74CZG7PHDK7RJH3UVWDHLANCNFSM5JACH4QQ> . 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 commented.Message ID: ***@***.***>

[Kantis]

@sksamuel this one's ready ✌🏼

[sksamuel]

It's been a while :)
Can you remind me what the matchEach is solving again.