Migrating to Spock 2, some errors happen when using parameter named `build`

[etiennestuder]

Issue description

When migrating to Spock 2, some tests previously green started failing. As crazy as it sounds, it turned out that renaming the parameters named build holding a Mock to some other name made the tests green again.

How to reproduce

• Check out https://github.com/etiennestuder/teamcity-build-scan-plugin
• Run gradlew build
• Change sbuild to build here
• --> test will fail

Link to a gist or similar (optional)

See this code change which turns the red tests back into green tests:
etiennestuder/teamcity-build-scan-plugin@75bfa6d#diff-9dac7f911ea3895bc8e7af5798850b91R26

Additional Environment information

---

Gradle 6.6-rc-2

Kotlin: 1.3.72
Groovy: 2.5.12
Ant: Apache Ant(TM) version 1.10.8 compiled on May 10 2020
JVM: 13.0.2 (Oracle Corporation 13.0.2+8)
OS: Mac OS X 10.15.6 x86_64

Java/JDK

openjdk version "13.0.2" 2020-01-14
OpenJDK Runtime Environment (build 13.0.2+8)
OpenJDK 64-Bit Server VM (build 13.0.2+8, mixed mode, sharing)

Build-tool dependencies used

Gradle/Grails

dependencies {
testImplementation 'org.spockframework:spock-core:2.0-M3-groovy-2.5'
testImplementation 'org.spockframework:spock-junit4:2.0-M3-groovy-2.5'
}

test {
useJUnitPlatform()
}

[Vampire]

Hm, very interesting.
I have no idea why this happens, but it can be boiled down to.

import spock.lang.Specification

class Foo extends Specification {
    def foo() {
        given:
        def build = Stub()
        build.toString() >> null

        expect:
        true
    }
}

where build.toString() >> null gets rewritten to

this.getSpecificationContext().getMockController().addInteraction(build.call())

instead of

this.getSpecificationContext().getMockController().addInteraction(new org.spockframework.mock.runtime.InteractionBuilder(7, 9, 'build.toString() >> null').addEqualTarget(build).addEqualMethodName('toString').setArgListKind(true, false).addConstantResponse(null).build())

Btw. your project does not build @etiennestuder, it complains that it cannot run mvnw.
I guess your build is optimized for Linux and I happend to try it on Windows.

[Vampire]

And during debugging it seems to create the correct code. :-/

[etiennestuder]

@Vampire It's a Gradle build. You can run it with ./gradlew.bat on Windows.

[etiennestuder]

@Vampire Thanks for having looked into it. I hope you find the cause and a fix for it.

[Vampire]

@Vampire It's a Gradle build. You can run it with ./gradlew.bat on Windows.

I know the one best build tool in the world and I'm even a contributor. ;-)
Nevertheless the Maven part of the build where the Gradle part tries to trigger the Maven wrapper is failing as described.
This didn't hinder me to test, just wanted you to know. :-)

[etiennestuder]

Nevertheless the Maven part of the build where the Gradle part tries to trigger the Maven wrapper is failing as described.
This didn't hinder me to test, just wanted you to know. :-)

My apologies, I finally got what you mean. This is what you were referring to:
https://github.com/etiennestuder/teamcity-build-scan-plugin/blob/ad83e74cf23b6a6736fb3eff73874fbf6d318117/agent/service-message-maven-extension/build.gradle#L10

I fixed it:
etiennestuder/teamcity-build-scan-plugin@ceec051

Thanks for letting me know.

[Vampire]

Regarding the reported problem, it is a Groovy bug: https://issues.apache.org/jira/browse/GROOVY-9651.
But we can work-around the problem.

[etiennestuder]

Cool. Thanks @Vampire

[etiennestuder]

Thanks, @leonard84 .