CODEWITHSUNDEEP
unit-testinggroovyspockstub
WILLIAM WOODMAN
WILLIAM WOODMAN

Reputation: 1231

Groovy per instance metaClass method override doesn't work as expected in Spock test

I have a class with method called execute(). In some Spock unit test I dummy out the execute method and give it a mock closure like this:

def setup () {
    rule = new DynamicRule ()
}

def "test default execution " (){
    given : "basic AORule "
    def mockres
    rule.metaClass.execute = {-> mockres = "did nothing"}     //mock the action
    def res = rule.execute()


    expect : "execute should do nothing "
    mockres == "did nothing"

}

If I run this test it fails. In the idea editor it shows the mock closure as underlined, but the rule.execute() on the next line isn't - so it can see the method.

If I change this test for this:

    rule.metaClass.execute2 = {-> mockres = "did nothing"}     //mock the action
    def res = rule.execute2()

then the test passes.

Outside of Spock I just ran a simple Groovy script and did the method overload and that works correctly as I'd expect and the method is mocked out with the closure 

class A {
    def execute () {
        println "thing"
    }
}

def c = new A()
def res
c.execute()

c.metaClass.execute  = {-> res =2 ; println "modified thing "; }

c.execute ()

println "res = "+  res

Why doesn't the same happen in the Spock test?

How do unit stub test a closure correctly for Spock?

This modified version of the test works successfully:

def "test default execution " (){
    given : "basic AORule "

    def mockres

    def stub = new StubFor(AORule)
    stub.demand.execute { mockres = "did nothing" }
//        rule.metaClass.execute = {-> mockres = "did nothing"}     //mock the action
//        def res = rule.execute()

    expect : "execute should do nothing "
    stub.use {
        rule.execute()
        mockres == "did nothing"

    }
}

Why didn't the simple per metaclass work in Spock?

Upvotes: 2

Views: 1350

Answers (1)

Jérémie B
Jérémie B

Reputation: 11022

This is an open issue on Groovy >= 2.4.3, here: GROOVY-7368.

There is a bug in the overriding of private methods with the metaclass.

Upvotes: 2

Related Questions