Spock  is a testing and specification library for Groovy and Java projects. Just recently I figured that quite a large number of Grails and Groovy developers I know are not aware of another really cool Spock feature: Mocking and Stubbing.
Mocking with Spock
A mock is an object of a certain type but without any behavior. Instead, the expected behavior is specified by the developer writing the specification. There is a large number of mocking libraries in the Java space, in my past Java projects I used EasyMock  quite frequently. The Spock developers made the decision to write their own mocking functionality being tightly integrated into the Spock library and using some of the Groovy language features that make code easier to read and maintain.
Enough said, let's see mocking in action. We have a class ItemProcessor. The ItemProcess processes and saves items. For saving the items, it has a dependency on another class: ItemRepository.
Now we have to write a specification for our ItemProcessor that ensures the items are saved via the ItemRepository. The Spock specification looks like this:
Mocks created by Spock are lenient by default. In other words: calls on mock methods which haven't been mocked return default values from their return types instead of throwing an error.
The way to create mocks in Spock is by using the Mock() method. The method does not come with any required parameters, although some variations of Mock() are available. In order to have the generic type information of the Mock return type, we will use the Mock(Class) interface for our example. Please note that ItemRepository is a concrete class, Spock allows mocking for interfaces and concrete classes, let it be Groovy or Java (!) classes.
Now comes the really cool part. We have to specify how many times we expect our save method from the repository to be called. This can be done with using a special Spock mocking DSL:
As can be seen in the code example above, the DSL expressions holds the cardinality (1 *), the target constraint (repository), the method constraint (save) and an argument constraint (_). The code uses the underscore as argument constraint. The underscore has a special semantic, it acts as "any" operator and can also be used for the other constraints. The mock spec above can be read as: "execute repository.save a single time no matter what in put arguments are given".
But we could use a true argument constraint either:
This restricts the mock to exactly that list of Item instances.
The Spock documentation  shows more examples for valid mock expressions:
Stubbing with Spock
Now we want to do some stubbing. For this case, let's assume the save method in the ItemRepository is rewritten to return the newly saved Items. We have to change our test-case to return a list of saved Item instances.
As you can see above, the right-shift operator is used to return a fixed value. If we would have used to underscore we could use the triple-right-shift operator for subsequent return values:
We could also use the "computed" return value feature to deduce the return value from the arguments to the method call which are available in the args variable:
Spying with Spock
Spies stub specific methods from otherwise concrete classes leaving the original methods as-is. In other words, that non-stubbed methods are delegated to a real object the stubbed methods overshadow the real methods. More on spies can be found in the Spock documentation .
This article should have given you a small pointer on what is possible with Spock's mocking and stubbing features. It is a really nice and mighty feature people new to Spock might not be aware of.