Passing GString to groovy-mocked method taking String argument yields IllegalArgumentException

[kriegaex]

Issue description

When creating a GroovyMock for a class with a method someMethod(String arg) and then passing a GString to it during a test, e.g. someMethod("foo ${1 + 1}"), it will yield java.lang.IllegalArgumentException: argument type mismatch.

For me this looks like a bug.

How to reproduce

package de.scrum_master.stackoverflow.q63797837

import spock.lang.Specification

class FooSpec extends Specification {
  def 'pass String to groovyMock mocked method taking a String argument'() {
    given:
    TestClass testClass = new TestClass()
    SomeClass someClass = GroovyMock()  // does not work, but Mock() does
    testClass.someClass = someClass

    when:
    testClass.callMethod()

    then:
    1 * someClass.someMethod(_)
  }

  static class SomeClass {
    String someMethod(String arg) {  // changing parameter type to GString works
      return arg
    }
  }

  static class TestClass {
    SomeClass someClass

    String callMethod() {
      someClass.someMethod("foo ${1 + 1}")
    }
  }

}

The (unfiltered) stack trace looks like this:

java.lang.IllegalArgumentException: argument type mismatch
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:104)
    at org.spockframework.mock.runtime.GroovyMockMetaClass.doInvokeMethod(GroovyMockMetaClass.java:83)
    at org.spockframework.mock.runtime.GroovyMockMetaClass.invokeMethod(GroovyMockMetaClass.java:39)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:41)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:127)
    at de.scrum_master.stackoverflow.q63797837.TestClass.callMethod(FooSpec.groovy:15)
    at de.scrum_master.stackoverflow.q63797837.TestClass$callMethod.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:119)
    at de.scrum_master.stackoverflow.q63797837.FooSpec.$spock_feature_0_0(FooSpec.groovy:28)
    ... 34 more

Link to a gist or similar (optional)

Origin: https://stackoverflow.com/q/63797837/1082681

Spock versions

Happens both in 1.3-groovy-2.5 and 2.0-M3-groovy-3.0

[kriegaex]

I just ran the same test with the current master and can confirm that it works for me now. Thanks for the swift bugfix! 😀

[pauxus]

Any chance of this being backported to a 1.3-bugfix? With Jenkins I am stuck with Groovy 2.4 for now...

[kriegaex]

@pauxus, I am not a maintainer here, but I remember Leonard's statement that due to resource limitations (development time), currently there is no plan to ever port back any functionality or even bugfixes to older versions. All fixes and features can only be expected in newer releases, the 1.x "branch" will not be maintained after 2.0 is out and in fact has not been maintained since the 1.3 release, which is also when 2.0 development began. So at present, the Spock development "tree" is strictly linear. I think Leonard also said that if someone would volunteer to actively maintain a 1.3 bugfix/backport branch, the team might reconsider. But as usual in OSS projects, things are only happening if someone steps up to actually do it.