Add new matcher syntax for comparing collections regardless of order

[leonard84]

Is your feature request related to a problem?

I'm always frustrated, when I want to make sure, that two collections have the same elements, regardless of their order.

The current way to do it, is to cast both to Set, e.g., x as Set == [1, 2, 3] as Set, but that is verbose. Also if you want to make sure that duplicate Elements are recognized as well, then you'll have to use something like Hamcrest's containsInAnyOrder.

Describe the solution you'd like

I'd like to be able to use a shorter Spock like syntax for comparing collections.
So, I propose to use =~ and ==~ for this:

• x =~ [1, 2, 3] would be a lenient match, i.e., casting both to Set before comparing
• x ==~ [1, 3, 3] would be a strict match, using containsInAnyOrder under the hood so that duplicate elements are verified as well.

Describe alternatives you've considered

No response

Additional context

The proposed matchers have some limitations as we will have to do this in the AST transformation during compile time. So we only have static data available, and we don't want to break the existing behavior.

Limitations

• Would only be applied if either of the Expression in the BinaryExpression
  • Is a VariableExpression which type is a known Collection subclass or Iterable
  • Is a ListExpression

  def "matchers"() {
    def x = [1]
    List y = [1]
    def z = [1]
    
    expect:
    x ==~ [1]  // works 
    x ==~ y    // works
    x ==~ z    // would default to normal Groovy Semantics as both are `Object` and fail for this case
  }

[leonard84]

@spockframework/supporter please give feedback

[timyates]

Would the third case work for x =~ z?

Would this break for people doing pattern matching at present?

    def "devils advocate"() {
        def x = 'tim'
        def y = '.*im'

        expect:
        x =~ y   // works as it returns a matcher which is truthy `true`
        x ==~ y  // works
    }

[leonard84]

Yes, it would keep the default groovy semantics. I've changed the text a bit to better reflect what is happening. With won't work I meant that it would not be transformed to the special collection handling and will behave the same as before.

Would this break for people doing pattern matching at present?

It shouldn't, as the none of sides would match the requirements for transformation I listed in Limitations above. If you can think of a scenario where it would cause conflicts let me know.

[erdi]

I'm always frustrated, when I want to make sure, that two collections have the same elements, regardless of their order.

Very much so. Using a hamcrest matcher for that with the ugly syntax is then only way I know. And every time I do that there is friction from the team because it's so unusual to use matchers with Spock and people fail to understand why it's actully needed. So as a feature in general it gets a 👍 from me.

[timyates]

It shouldn't, as the none of sides would match the requirements for transformation I listed in Limitations above. If you can think of a scenario where it would cause conflicts let me know.

Awesome! I too am tired of as Set cluttering up the place 😉

[kriegaex]

I like the feature. The syntax also looks good to me. Given proper documentation, I think it would potentially benefit many users.

I don't know anything about AST, which information is available in which phase and how type inference works for def x = [1]. So I am apologising in advance if this is a naive question, but isn't there a way to utilise type inference by generating Groovy code which checks for iterables and collection types during runtime in order to cover the 3rd case? Probably it would be slow, but in a test it would not matter much and also just be limited to places using ==~.

[leonard84]

So I am apologising in advance if this is a naive question, but isn't there a way to utilise type inference by generating Groovy code which checks for iterables and collection types during runtime in order to cover the 3rd case?

Hm, we could probably add a "dynamic variant" that we fall back to if we can't ascertain the types statically to determine whether it is a regex or collection comparison. However, I'm not sure yet how to best do this while keeping the generated code manageable and also preserving good diagnostics. I'll keep it in mind for now.

[marcphilipp]

I like it! 😍

[jochenberger]

This behaved differently if the collection members have different types:

package org.example

import spock.lang.Specification

class ExampleSpec extends Specification {

    def "lenient match with different types"(){
        expect:
        [1, 2, 3] =~ [1l, 2l, 3l]
    }

    def "strict match with different types"(){
        expect:
        [1, 2, 3] ==~ [1l, 2l, 3l]
    }
}

The first feature succeeds, the second one fails with:

Condition not satisfied:

[1, 2, 3] ==~ [1l, 2l, 3l]
          |
          false

Expected: iterable with items [<1L>, <2L>, <3L>] in any order
     but: not matched: <1>

	at org.example.ExampleSpec.strict match with different types(ExampleSpec.groovy:14)+#

Should I open an issue for that?