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

Mocking in given block is ignored when mocked in setup method #962

Open
huehnerlady opened this Issue Jan 15, 2019 · 12 comments

Comments

Projects
None yet
5 participants
@huehnerlady
Copy link

huehnerlady commented Jan 15, 2019

Issue description

Currently you can declare a certain mocked behaviour in the setup method, which will then be used for every test in the class. If you want to override that behaviour you HAVE to put it in the then block. This is very confusing to people as it is not the natural flow they would describe the test

How to reproduce

groovy example of a test

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
      } 
}

Tests in words:

myMethod should always return 1

testing regular behaviour
When myMethod is called
Then the result is 1

testing exceptional behaviour
Given myMethod returns 2
When I call myMethod
Then the result is 2

In this case the second test will fail
You would have to write something like

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

In words:

When I call myMethod
Then any call of myMethod returns 2
and the result is 2

To me the first wording of the test is a natural flow in comparison to the second version.
So my proposal is to add the given block to override the declarations of the setup-Method.

It is Important though, that the then-Block should still always win as you need to verify how often methods are called as well.

@EduardoSolanas

This comment has been minimized.

Copy link

EduardoSolanas commented Jan 15, 2019

Thanks @huehnerlady +1

@huehnerlady

This comment has been minimized.

Copy link
Author

huehnerlady commented Jan 17, 2019

@robfletcher @leonard84 could you maybe have a look at this as you were looking at the similar issue this one was created from?

@huehnerlady

This comment has been minimized.

Copy link
Author

huehnerlady commented Mar 15, 2019

Is there the possibility to get some answer here? It is open for 2 months now...

@huehnerlady

This comment has been minimized.

Copy link
Author

huehnerlady commented Mar 29, 2019

@leonard84 @Vampire @MartyIX can please someone take a statement to my issue? It is open since middle of January and nobody answered which is really disappointing!

@MartyIX

This comment has been minimized.

Copy link
Contributor

MartyIX commented Mar 29, 2019

@huehnerlady I'm not affiliated with Spock in any way. I have just contributed a few patches. You can try https://gitter.im/spockframework/spock though :)

@huehnerlady

This comment has been minimized.

Copy link
Author

huehnerlady commented Mar 29, 2019

@MartyIX sorry I just took the people that contributed in the last few months, but thanks I will try that :)

@Vampire

This comment has been minimized.

Copy link
Contributor

Vampire commented Mar 29, 2019

Same for me, it is pretty rude to randomly ping contributors. If at all, ping team members. But actually, this is an open source project where people contribute their sparse spare time, so you cannot always expect timely answers. You could fix the behaviour and send a patch though. ;-)

1 similar comment
@Vampire

This comment has been minimized.

Copy link
Contributor

Vampire commented Mar 29, 2019

Same for me, it is pretty rude to randomly ping contributors. If at all, ping team members. But actually, this is an open source project where people contribute their sparse spare time, so you cannot always expect timely answers. You could fix the behaviour and send a patch though. ;-)

@huehnerlady

This comment has been minimized.

Copy link
Author

huehnerlady commented Apr 1, 2019

@Vampire I am really sorry, I did not think of that. I did try to address the issue as recommended by MartyIX.

but the patch is a good idea as well, thanks

@leonard84

This comment has been minimized.

Copy link
Member

leonard84 commented Apr 3, 2019

@huehnerlady sorry for the late answer. We are working on spock-2.0 at the moment, so please wait for contributions until that branch is merged to master, otherwise it will create unnecessary effort.

Regarding your issue, as I said in #321 there is a current working way to override the setup behavior, so I see the priority not so high.

Furthermore, the semantics are unclear. From a user endpoint I could read two things happening for given: myInterface.myMethod() >> 2:

  • invocations of myMethod return 1 for the first, and 2 for the second invocation
  • it always returns 2
@huehnerlady

This comment has been minimized.

Copy link
Author

huehnerlady commented Apr 4, 2019

the problem is as described in the other issue that it is confusing the way it is at the moment, as you have to override things in the then block instead of the given block.

To me the behaviour is clear as you do not want to add functionality but override existing functionality, so it would be the second approach.

Keep in mind that this is how junit works as well.

When will the 2.0 branch be merged into master?

Many thanks

@leonard84

This comment has been minimized.

Copy link
Member

leonard84 commented Apr 4, 2019

@huehnerlady

Keep in mind that this is how junit works as well.

JUnit does not provide any mocking functionality that I know of. Did you mean Mockito?

When will the 2.0 branch be merged into master?

Let me quote Blizzard here, when it's done ;) as @Vampire already mentioned above we work on this in our spare time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.