spock: interactions in given/setup blocks should have precedence over those in setup methods

Originally reported on Google Code with ID 199

Describe the enhancement you have in mind.

interactions in given/setup blocks should have precedence over those in setup methods
as discussed in: http://groups.google.com/group/spockframework/browse_thread/thread/3e20f7466dd6248b

Is it possible to override the behaviour (return value) for one
specific test method: see example below (also available at:
http://meetspock.appspot.com/script/36001)
"testing exceptional behaviour" fails where I want it to succeed

interface MyInterface {
    int myMethod()

}

class MyInterfaceTest extends Specification {
    def myInterface = Mock(MyInterface)

    def setup() {
        myInterface.myMethod() >> 1
    }

    def "testing regular behaviour"() {
        when:
         def result = myInterface.myMethod()
        then:
         result == 1
     }

    def "testing exceptional behaviour"() {
        given:
         myInterface.myMethod() >> 2
        when:
         def result = myInterface.myMethod()
        then:
         result == 2
      } 
}

Which particular problem would this enhancement solve for you?
it would ease the setup of testing expetional behaviour, where for all other tests
use the same 'normal' behaviour of the mock, so you don't have to setup this for each
test.


Please provide any additional information below. You can also assign
labels.

Reported by frederic.pape on 2011-09-13 11:08:13

About this issue

Original URL
State: closed
Created 9 years ago
Reactions: 3
Comments: 23 (7 by maintainers)

Commits related to this issue

Added configurable interaction matching By default Spock uses a match first algorithm to determine the defined return value of a method. So whenever there are multiple defined return values, it will ... — committed to BoukeNijhuis/spock by BoukeNijhuis 4 years ago

Most upvoted comments

@vanta it might look like a hack to you, but it is not. What you describe is just adding another stub call after the first one. Changing that behavior would break the existing code for many others, and having a valid way to override it I don’t see it as necessary to change it. Keep in mind that adding more ways to do the same thing will complicate the syntax and makes it harder for everyone, to understand what is happening.

People that knows spock will fix it quickly we have to try to bring more people into the fold, and those people are using Junit.

I am migrating every single project that I find from Junit into Spock, training everyone and this bug is very confusing for new people used to Junit

EduardoSolanas on Jan 14, 2019

@vanta it might look like a hack to you, but it is not. What you describe is just adding another stub call after the first one. Changing that behavior would break the existing code for many others, and having a valid way to override it I don’t see it as necessary to change it. Keep in mind that adding more ways to do the same thing will complicate the syntax and makes it harder for everyone, to understand what is happening.

leonard84 on Jan 14, 2019

This issue was created in 2011, any update on it? It’s still marked “New”…

vanta on May 10, 2016

I think the best way to do this while retaining a) backward compatibility and b) make it optional (sometime I don’t want it to be overriden) would be a new syntax/method, something like:

def "overriding setup mocks"() {
    given:
    myMock.redefine {
        oldMethod >> "bla"
    }

    ....
}

pauxus on Jan 21, 2016

As a workaround while keeping the Behaviour Definition at the right place, I did currently sth like this:

class MyInterfaceTest extends Specification {
    def myInterface = Mock(MyInterface)
    def myMethodReturn

    def setup() {
        myMethodReturn = 1
        myInterface.myMethod() >> {return myMethodReturn}
    }

    def "testing regular behaviour"() {
        when:
         def result = myInterface.myMethod()
        then:
         result == 1
     }

    def "testing exceptional behaviour"() {
        given:
         myMethodReturn = 2
        when:
         def result = myInterface.myMethod()
        then:
         result == 2
      } 
}

alwinmark on Aug 31, 2015