Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

kriegaex opened this issue Sep 13, 2020 · 3 comments · Fixed by #1217


Copy link

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'() {
    TestClass testClass = new TestClass()
    SomeClass someClass = GroovyMock()  // does not work, but Mock() does
    testClass.someClass = someClass


    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(
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(
    at java.lang.reflect.Method.invoke(
    at org.codehaus.groovy.reflection.CachedMethod.invoke(
    at org.spockframework.mock.runtime.GroovyMockMetaClass.doInvokeMethod(
    at org.spockframework.mock.runtime.GroovyMockMetaClass.invokeMethod(
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(
    at de.scrum_master.stackoverflow.q63797837.TestClass.callMethod(FooSpec.groovy:15)
    at de.scrum_master.stackoverflow.q63797837.TestClass$ Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(
    at de.scrum_master.stackoverflow.q63797837.FooSpec.$spock_feature_0_0(FooSpec.groovy:28)
    ... 34 more

Link to a gist or similar (optional)


Spock versions

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

Copy link
Contributor Author

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

Copy link

pauxus commented Dec 11, 2020

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

Copy link
Contributor Author

kriegaex commented Dec 17, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging a pull request may close this issue.

2 participants