`containsKey` missing method when in a `with` block

[mkobit]

I noticed this earlier when trying to make some assertions on a map.

Here is an example feature method with groovy-all:2.4.6 and spock-core:1.0-groovy-2.4 in gradle:

def "map containKey works as expected"() {
  given:
  def map = [myValue: 'hey', otherValue: 'helloagain']

  expect:
  with(map) {
    size() == 2
    containsKey('myValue')
    containsKey('otherValue')
  }
}

This fails with:

No signature of method: MySpec.containsKey() is applicable for argument types: (java.lang.String) values: [myValue]
groovy.lang.MissingMethodException: No signature of method: MySpec.containsKey() is applicable for argument types: (java.lang.String) values: [myValue]
    at MySpec.map containKey works as expected(MySpec.groovy:59)

If I change both of the containsKey methods instead to use the implicit it, like it.containsKey it works as expected.

Is this expected behavior? Am I missing something about how the AST transformations happen?

[angry-cellophane]

I made some investigation on it. Here what I've found:

with(map) {
  size() == 2
  containsKey('myValue')
}

will translate into something like this (simplified):

SpockRuntime.verifyCondition(Boolean.valueOf(ScriptBytecodeAdapter.compareEqual(ScriptBytecodeAdapter.invokeMethodOnCurrent0(withClosure, this, "size")), 2))
SpockRuntime.verifyMethodCondition(this.getThisObject(), "containsKey", "myValue")

As you can see, size() is invoked on the closure (which has map as the delegate and resolve strategy = delegate first), whereas containsKeys() is invoked on this.getThisObject() which is the current spec (your test class).

Seems like a bug.

[angry-cellophane]

I can make the fix

[szpak]

@angry-cellophane Your proposal sounds sensible (at least I see no reasons why the solution should not work :) ). If you liked to provide a PR it would be great. However, please pay attention to write proper tests to verify a case when a method from a specification (or applied trait) should be still called (if not found in a closure).

[angry-cellophane]

PR - #606

[aaabramov]

@szpak should this issue be closed? Seems that PR has been merged.

[szpak]

Yup

[aaabramov]

@szpak unfortunately, I have no rights to do that. I am not an author

[szpak]

I know. In the meantime I asked offline the people with write access to that repo to close it by the way.