JSONMatcherBuilder.makeMatcher should support unordered list

[michussey69]

It would be helpful to add a method to cause the matcher not to care in which order list elements are presented (equivalent to JSONMatcherBuilder(nestSchema).ignoreMissingFields(true);

[michussey69]

The method could be called ignoreListElementOrder()

[sbarber2]

Ah, then JSONMatcherBuilderNestedTest.testNestedArray6() is relevant to this issue more than to Issue #6.

So, let me poke at your functional requirements here a bit; I think we need a bit more requirements elaboration.

A list is an ordered sequence of values, so that lists whose elements represent identical sets but whose elements appear in a different order are not usually considered to be equivalent or equal.

Given that the StreamBase type system doesn't provide a Set or Multiset type, I can see why you might want to use a list to represent one or both of these in an application whose semantics require those abstractions.

This raises the question: what should your proposed ignoreListElementOrder() do about duplicated values? Perhaps we want an ignoreListElementMultiplicity() as well?

The next question: if I call new JSONMatcherBuilder(nestSchema).ignoreListElementOrder() and there are multiple fields in the schema of type list, should the returned matcher ignore order for all list fields in the schema? What if want to ignore element order only for some of the list fields, but enforce it for others?

[michussey69]

Yes - JSONMatcherBuilderNestedTest.testNestedArray6() was intended to illustrate this requirement.

I guess the confusion comes through me looking at the JSON representation which is an array, not a list.
But as you suggest there's nothing stopping me at the application level deciding to ignore list order and treat {a, b, c} the same as {b, a, c}

So I would like to be able to write test cases where
expect {a, b, c} receive {b, c, a} is a pass
expect {a, b, c} receive {b, c, a} is a fail
expect {a} receive {b, c, a} is a pass
expect {a} receive {b, c, a} is a fail
etc

From what I can see the existing SBUnit only applies these sort of flags globally on the matcher as a whole, so I wouldn't expect to be able to enforce order for one list in a tuple but not another.

Unless you want to come up with a whole new semantic for describing the expected tuple in JSON? Which should be able to say things like
this list should have 4 elements, and in the 3rd element the value of the attribute "id" should begin with "foo"