Sinon: Matcher that verifies equality independent of array order

[pvdlg]

It would be helpful to add a matcher to verify that an Array parameter contains exactly some values independently of the order.

Currently sinon.match.array.deepEquals(arr) is order sensitive and sinon.match.array.contains(arr) doesn't verify that the Array parameter doesn't contain values not present in the expectation.

It could be a new matcher called sinon.match.array.containsExactly(arr) or something similar.
Or it could be a matcher that verify the length of an array so we could do:
sinon.match.array.containsExactly(arr).and(sinon.match.array.length).

[mroderick]

Would it be sufficient to just sort your values before comparing them?

const expected = [1, 3, 2].sort();
const actual = [3, 2, 1].sort();

assert.equal(actual, expected);

[pvdlg]

@mroderick that's a valid workaround in some cases, but using matchers is much more convenient, especially with calledWith as it allow to verify at least one of the call match.

[mroderick]

There are slight variations over the use of equality in different test libraries, which makes it harder for newcomers to get a good handle on things. I don't think anyone wants to contribute to that.

With that in mind, I think we should be very careful when naming assertions and matchers in ways that can be mistaken for equality (strict, deep, etc).

How about sinon.match.array.isEquivalent?

Combined with some decent documentation, I think we can make it clear how this slots into the gap between the other matchers.

[pvdlg]

sinon.match.array.isEquivalent would be great!
I can create a PR sometime this week if you are interested.

[fatso83]

I don't fancy the name at all. The arrays need not be equivalent, depending on how you define it.

Mathematics.(of two sets) able to be placed in one-to-one correspondence.

containsExactly strikes me as better as it relates to the contents of the array, not the array itself.

[lucasfcosta]

Hi folks and thanks @vanduynslagerp for your suggestion 😄 !

I'm gonna give my 2 cents on this.

I think that matchers do have their use cases, but, personally, I don't like them that much because they allow loose assertions, which are assertions that either indicate non-determinism or just might make it easier for your tests to pass even when there are wrong things.

I feel like this is an assertion related problem.

I like to view the testing ecosystem as a huge pile of small blocks which can be used together to create things. I really like the Unix philosophy of doing one thing and doing it well and making things that work together.

I feel like this is not the use case for matchers, I just feel like this is where an assertion library might come in handy.

Personally, I never use matchers. I try to be as strict as possible in my assertions, but I understand why some of them exist, even though I advocate against.

This is also something we have already discussed a lot on Chai.js, because we ended up adding too many loose assertions, which let our users do whatever they want, but end up creating a "wrong" mindset.

I might have been a bit philosophical here but I think that the more we focus on doing one thing (stubs, mocks, spies and this kind of stuff) the better we will be at it.

Also, if you want to read more about my opinion on assertions, here is a blog post I've written about it.

However, I'd like to make clear that I'm very open to hearing other opinions on this matter and I'd like to thank you for your suggestion. It's great to have people's feedback.

Please let me know if you disagree with anything.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.