Closed GoogleCodeExporter closed 9 years ago
This is expected because interactions specified in a then-block currently have
precedence over interactions specified elsewhere. And because the interaction
in the then-block doesn't specify a return value, the default value for the
mocked method's return type (null in this case) is returned.
Does this behavior cause you any troubles? In general, you shouldn't (have to)
specify overlapping interactions (i.e. interactions that match the same calls).
Original comment by pnied...@gmail.com
on 28 Sep 2010 at 12:16
Dear Peter,
Beautiful. I completely agree with your reasoning. If Spock will allow
overlapping interaction(s) in both setup and then, that may cause confusion and
redundancy.
I was researching online and came across this:
http://meetspock.appspot.com/?id=16001
There is a spec: "Mocking and checking interaction works"() on line number 15.
Looking at it I thought it is possible to have same interaction in given and
then, kind of like Mockito.
Consider this issue closed. I like your explanation, may be we can specify it
in the Wiki if it is not already done.
Conversely, I am presenting on Mockito and Spock tomorrow
http://www.sunjug.org/september-2010. Let me know if you would like information
on it like the demo project on Git for your documentation purposes etc.
Original comment by ravi.has...@gmail.com
on 28 Sep 2010 at 1:40
>If Spock will allow overlapping interaction(s) in both setup and then, that
may cause confusion and redundancy.
Technically, Spock does allow this, but one interaction will always "win". If
the stubbed interaction is found first (see below for search order), it will
always match (as it has no cardinality), and the other interaction won't ever
get a chance to match. If the mocked interaction is found first, it will match
until the expected number of invocations has been reached; the next call will
cause a TooManyInvocationsError. (By the way, the exception name is stolen from
Mockito).
Search order for interactions is:
1. then-block
2. setup method
3. spec method (e.g. setup-block)
The main reason why then-blocks come first is to allow you to override
interactions specified, say, in a setup method. I'm not 100% sure this is the
right decision, but that's how it works at the moment.
Many people think that Spock's mocking framework works like Mockito because it
also allows to specify interactions after the fact. But in reality, it works
more like EasyMock and JMock. That is, the interactions must be known
beforehand. Spock achieves this by moving interactions in then-blocks before
the corresponding when-block (at compile time). Compared to Mockito, this has
advantages (e.g. a single interaction can be used for mocking AND stubbing) and
drawbacks (if you factor out interactions into a helper method and insist on
calling the helper method from a then-block, you have to wrap the call with
"interaction { ... }" to help Spock understand that the helper method contains
interactions).
>Looking at it I thought it is possible to have same interaction in given and
then, kind of like Mockito.
Yeah, that example gives a wrong impression (it was written by someone else).
>I like your explanation, may be we can specify it in the Wiki if it is not
already done.
The documentation is definitely lacking, in particular for the mocking
framework. We'll work on this for 0.5/0.6.
>Conversely, I am presenting on Mockito and Spock tomorrow
http://www.sunjug.org/september-2010. Let me know if you would like information
on it like the demo project on Git for your documentation purposes etc.
Cool! I'd definitely like to see your presentation. By the way, for people who
don't want to give up on Mockito, there is also the option of using it together
with Spock, enjoying Spock's other benefits.
Original comment by pnied...@gmail.com
on 28 Sep 2010 at 3:30
Original comment by pnied...@gmail.com
on 28 Sep 2010 at 3:31
I will be blog my presentation and I will send you the link. The code is on
GitHub. Need to clean it up a little bit, before I show it to you :-)
Also, I tried to use Mockito and Spock in same project. I couldn't. Mockito
doesn't seem to work beyond JUnit 4.4 and Spock needs Junit 4.7. I am using
Maven on my project and I am a noob to Maven. So I could be doing something
wrong. Your thoughts? Any way is there a way I can get in touch with you
directly? Don't want to spam your issue comment section with irrelevant
comments!!
Original comment by ravi.has...@gmail.com
on 29 Sep 2010 at 2:45
I think the JUnit version problem can be solved. The best place to discuss such
things is the Spock forum: http://forum.spockframework.org
Original comment by pnied...@gmail.com
on 29 Sep 2010 at 9:27
Original issue reported on code.google.com by
ravi.has...@gmail.com
on 28 Sep 2010 at 12:02Attachments: