Alter the plugin to use stricter "to satisfy" semantics.

[alexjeffburke]

The behaviour of allowing a set to compare against an array as part
of "to satisfy" has shown itself to be surprising - exclude this
behaviour from "to satisfy" and rename it as a separate assertion
which still allows an array-like on the RHS.

Perhaps more importantly a non-exhaustive satisfy passed with a
subset on the RHS. This is another very surprising behaviour given
arrays in core enforce an equal length. Switch to enforcing the Set
being equal size by default.

[papandreou]

Ah, nice!

I thought I volunteered to do this, but luckily I didn't have a chance to work on it yet :)

Remember to fix the documentation tests too.

[alexjeffburke]

Ah, nice!

I thought I volunteered to do this, but luckily I didn't have a chance to work on it yet :)

Remember to fix the documentation tests too.

Oh I'm sorry if I took your thunder - just thought I'd provide a head start since I had a few spare mins the other day.

[papandreou]

Oh I'm sorry if I took your thunder

No worries, I hadn't started :)

[coveralls]

Coverage increased (+3.7%) to 96.809% when pulling 6f74783 on stricter-satisfy-semantics into f0473c6 on master.

[alexjeffburke]

Around the question of whether the members of a set should be allowed to have things missing - the documentation examples might be a good guide.

The thing that gave me pause for thought was the following case:

expected Set([ 1, 2, 3 ]) to satisfy
Set([
  1,
  expect.it('to be less than or equal to', 1),
  expect.it('to be greater than', 10)
])

Set([
  1,
  2, // should be removed
  3 // should be removed
  // missing: should be greater than 10
])

The RHS specifies three items, but two of those things are satisfied by the same element on the LHS. I guess what this pokes at is what "exhaustively" really means when applied to Set comparisons.

[papandreou]

I still think that <Set> to satisfy <Set> and <Set> to [exhaustively] satisfy <Set> should mean the same thing at the first level. The current semantics are just too surprising.

[papandreou]

LGTM 😌

[alexjeffburke]

@papandreou turns out there was already a (seemingly) undocumented "to have items satisfying" assertion in the plugin - I've adjusted this to the new semantics and added documentation. Please have another look :)

[papandreou]

Looks good, just some objections against the to have items satisfying implementation.

[papandreou]

LGTM ⚡