Spocklight: Using Mock Method Arguments in Response

When we mock or stub methods we can use the method arguments passed to the method in the response for the mocked or stubbed method. We must write a closure after the rightShift operator (>>) and the closure arguments will resemble the arguments of the mocked or stubbed method. Alternatively we can use a single non-typed argument in the closure and this will contains the method argument list.

Continue reading

Tasty Test Tip: Matching generic typed classes in Mockito

Say you have a arbitrary class under test, which is dependent on a class DataProcessor which has a method with the following signature:

you might want to stub it with Mockito 1.9.5 in the following way to match the generic typed class:

However running this, gives the following error:

This is caused by the generic typed MulitvaluedMap.


Run the test and it will pass (these lines at least :-)!

Original Post

Change return value of mocked or stubbed service based on argument value with Spock

Albert van Veen wrote a blog post about Using ArgumentMatchers with Mockito. The idea is to let a mocked or stubbed service return a different value based on the argument passed into the service. This is inspired me to write the same sample with Spock.

Spock already has built-in mock and stub support, so first of all we don’t need an extra library to support mocking and stubbing. We can easily create a mock or stub with the Mock() and Stub() methods. We will see usage of both in the following examples.
Continue reading

Mock a superclass method with Mockito

Say you want to test a method from class which extends some kind of superclass. Sometimes you can be dependent on code in the superclass, which is undesirable in a test.

Now actually, the first thing you should consider is to refactor your code, because it’s violating the Single Responsibility design principle:
there is more than one reason why your class is subject to change. Another advice is to favor composition over inheritence. In this way you can mock the code you are collaborating with.

Having said that, sometimes you run into legacy code you just have to work with and aren’t able to refactor due to circumstances. Here’s a trick I found on Stackoverflow to “mock” a superclass method to do nothing with mockito. Continue reading

Using ArgumentMatchers with Mockito

Mockito is a mock framework which you can use to write simple and clean tests. One of it’s nice features is the ArgumentMatcher. With the ArgumentMatcher you can determine the outcome of your mocked service or repository based on any condition you want.

Imagine we have a CandyService which can get a list of candies which are liked by a specific customer. This service uses the external ChocalateService which specifically checks if the customer likes chocolate. Continue reading

Auto inject dependencies in JUnit using Mockito

While writing unit tests, you often have to mock dependencies like services or controllers. Often  a constructor is used to autowire the dependencies as shown in the example below. In the Test class I instantiated the ContactService using a contactRepository Mock object

The test class:

In the previous example you always have to Autowire the constructor and bind the dependencies to the class variables. In the next example the code is cleaner by autowiring the mocking objects, so you don’t have to create a custom constructor or setters to set the dependencies, which makes your code more concise and easier to read.

The test class:

Take a note of the “RunWith(MockitoJUnitRunner.class)” annotation. This annotation will initialize the annotated mock objects. An alternative is to use “MockitoAnnotations.initMocks(this)” in a setup method to initalize the annotated mock objects.

More tips can be found on the Mockito RefCard: http://refcardz.dzone.com/refcardz/mockito or take a look at the mockito site: http://www.mockito.org.