Slightly improved tests for loadRange method

[bijela-gora]

This PR is more a question then a suggestion.

The question: should we care about an order in which StorageAdapterInterface.loadRange returns data?

When I utilized expect.arrayContaining in this commit bijela-gora@3238d7a to automerge-repo I'm sure I didn't consider that. Now, I'm not even sure why I used that asymmetric matcher. The expect.arrayContaining does not care about an order of elements inside arrays:

describe('expect.arrayContaining', () => {
	it("doesn't care about order", () => {
		expect([0, 1, 2]).toEqual(expect.arrayContaining([2, 0]))
	})
})

I noticed that a day ago when I was trying to make a storage adapter based on node:sqlite. For some reasons better-sqlite3 and node:sqlite for the same SQL statement returns results ordered differently. I tested that with latest version of better-sqlite3 and with latest Node.js because latest versions uses the same SQLite version

[pvh]

Hi @bijela-gora -- sorry for the delay in getting back to you on this but to answer your question, I think we should not insist on ordering range data unless a serious need arises. If we guarantee an order then providers that aren't ordered will have to sort their keys before returning them and right now Automerge doesn't actually require the responses to be ordered (though it does go faster if they're at least semi-ordered).

[pvh]

(Landing this stricter test.)

[bijela-gora]

Thank you for the response!
If the ordering is not important, probably this change should be reverted.

• the toStrictEqual([]) does care about order.
• the toStrictEqual(expect.arrayContaining() doesn't.