Unexpected matching logic

[mantoni]

To my surprise, the following passes:

assert.match(
  { array: [1, 2, 3], more: true },
  { array: [2] }
)

My expectation would be that the above would fail due to the array not being equal. The following should pass:

assert.match(
  { array: [1, 2, 3], more: true },
  { array: [1, 2, 3] }
)

This differs from how Sinon.JS matchers work:

const spy = sinon.spy()
spy({ array: [1, 2, 3], more: true })

spy.calledWithMatch({ array: [1, 2, 3] }) // true
spy.calledWithMatch({ array: [2] }) // false

I prefer the Sinon match logic, because it allows me to explicitly state what I expect with nested matchers:

spy.calledWithMatch({ array: sinon.match.array.contains([2]) })

If we're merging the matcher logic, I think we should basically replace the referee logic with the Sinon implementation, especially since the user base is a tad larger over there.

[mroderick]

Good point. We should probably look into finishing that work

[mroderick]

I'll see if I can get it closer this weekend, as I am having a hack day with @khamiltonuk

[mantoni]

Oh nice! That'd be awesome. Unfortunately, I don't have the time to look into the implementation myself rn, but I'm happy to review and assist.

[mroderick]

Is this still broken?

[mantoni]

Yes, this is also relevant with the next branch of samsam. The matching logic didn't change.

[mantoni]

This was addressed in #50.