Japanese Groovy Mocks Add comment to Wiki View in Wiki Edit Wiki page Printable Version

Groovy Mocks





An ordinary Groovy or Java class that's instance or class methods are to be called.

Calling them can be time consuming or produce side effects that are unwanted when testing (e.g. database operations).




A Groovy Object that calls methods on the Collaborator, i.e. collaborates with it.

GroovyオブジェクトはCollaboratorからメソッドを呼びます。(例:collaborates with it. )


An object that can be used to augment the Collaborator. Method calls to the Collaborator will be handled by the Mock, showing a demanded behavior. Method calls are expected to occur strictly in the demanded sequence with a given range of cardinality. The use of a Mock implicitly ends with verifying the expectations.

オブジェクトはCollaboratorを増やすために使用されます。メソッドは 要求された 振る舞いを表すMockから扱うためにCollaboratorを呼びだします。メソッドコールは与えられた 範囲 の数から 要求された シーケンスを 厳密に 実行されることが 予期 されます。


Much like a Mock but the expectation about sequences of method calls on the Collaborator is loose, i.e. calls may occur out of the demanded order as long as the ranges of cardinality are met. The use of a Stub does not end with an implicit verification since the stubbing effect is typically asserted on the Caller. An explicit call to verify can be issued to assert all demanded method calls have been effected with the specified cardinality.

Mockと同様ですが、Collaboratorの一連のメソッドコールの 期待 は比較的 ルーズ です。例えば、コールは値の 範囲 が満たされる限り、 要求された 順番通りに 起こらない かもしれません。スタブ効果がCallerから通常アサートされるので、Stubは暗黙の検証で 終わりません検証する ために明白な呼び出しが特定の値とともに全ての 要求され 影響を受けたメソッドコールをアサートするために発行されます。

An extended example


System under test


We will explore a system under test inspired from the JBehave currency example.


Our system makes use of a base currency class used to represent the currency of a particular country:


and a base exchange rate class which encapsulates buying and selling rates for a currency:


We will make use of an exchange rate service collaborator to retrieve the exchange rates for a particular country:


Our class under test is a currency converter. It makes use of the following exception:


and conforms to the following interface:


Here is our class under test.


Mocking using Map coercion

Mocking using Map coercion

When using Java, Dynamic mocking frameworks are very popular. A key reason for this is that it is hard work creating custom hand-crafted mocks using Java.


Such frameworks can be used easily with Groovy if you choose (as shown in this extended example) but creating custom mocks is much easier in Groovy.


You can often get away with simple maps or closures to build your custom mocks.


Let's consider maps first.


By using maps or expandos, we can incorporate desired behaviour of a collaborator very easily as shown here:


For more details, see Developer Testing using Maps and Expandos instead of Mocks.



Results of your search request can come from various sources: the Groovy website itself, the JIRA issues, the API documentation, as well as a few other interesting Groovy-related blogs.

  By  -  pages  -  views  - last modified