Difference Between Stub, Mock, and Spy in the Spock Framework

1. Overview

In this tutorial, we’re going to discuss the differences between Mock, Stub, and Spy in the Spock framework. We’ll illustrate what the framework offers in relation to interaction based testing.

Spock is a testing framework for Java and Groovy that helps automate the process of manual testing of the software application. It introduces its own mocks, stubs, and spies, and comes with built-in capabilities for tests that normally require additional libraries.

First, we’ll illustrate when we should use stubs. Then, we’ll go through mocking. In the end, we’ll describe the recently introduced Spy.

2. Maven Dependencies

Before we start, let’s add our Maven dependencies:

<dependency>
    <groupId>org.spockframework</groupId>
    <artifactId>spock-core</artifactId>
    <version>1.3-RC1-groovy-2.5</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.codehaus.groovy</groupId>
    <artifactId>groovy-all</artifactId>
    <version>2.4.7</version>
    <scope>test</scope>
</dependency>

Note that we’ll need the 1.3-RC1-groovy-2.5 version of Spock. Spy will be introduced in the next stable version of Spock Framework. Right now Spy is available in the first release candidate for version 1.3.

For a recap of the basic structure of a Spock test, check out our introductory article on testing with Groovy and Spock.

3. Interaction Based Testing

Interaction-based testing is a technique that helps us test the behavior of objects – specifically, how they interact with each other. For this, we can use dummy implementations called mocks and stubs.

Of course, we could certainly very easily write our own implementations of mocks and stubs. The problem appears when the amount of our production code grows. Writing and maintaining this code by hand becomes difficult. This is why we use mocking frameworks, which provide a concise way to briefly describe expected interactions. Spock has built-in support for mocking, stubbing, and spying.

Like most Java libraries, Spock uses JDK dynamic proxy for mocking interfaces and Byte Buddy or cglib proxies for mocking classes. It creates mock implementations at runtime.

Java already has many different and mature libraries for mocking classes and interfaces. Although each of these can be used in Spock, there is still one major reason why we should use Spock mocks, stubs, and spies. By introducing all of these to Spock, we can leverage all of Groovy’s capabilities to make our tests more readable, easier to write, and definitely more fun!

4. Stubbing Method Calls

Sometimes, in unit tests, we need to provide a dummy behavior of the class. This might be a client for an external service, or a class that provides access to the database. This technique is known as stubbing.

A stub is a controllable replacement of an existing class dependency in our tested code. This is useful for making a method call that responds in a certain way. When we use stub, we don’t care how many times a method will be invoked. Instead, we just want to say: return this value when called with this data.

Let’s move to the example code with business logic.

4.1. Code Under Test

Let’s create a model class called Item:

public class Item {
    private final String id;
    private final String name;

    // standard constructor, getters, equals
}

We need to override the equals(Object other) method to make our assertions work. Spock will use equals during assertions when we use the double equal sign (==):

new Item('1', 'name') == new Item('1', 'name')

Now, let’s create an interface ItemProvider with one method:

public interface ItemProvider {
    List<Item> getItems(List<String> itemIds);
}

We’ll need also a class that will be tested. We’ll add an ItemProvider as a dependency in ItemService:

public class ItemService {
    private final ItemProvider itemProvider;

    public ItemService(ItemProvider itemProvider) {
        this.itemProvider = itemProvider;
    }

    List<Item> getAllItemsSortedByName(List<String> itemIds) {
        List<Item> items = itemProvider.getItems(itemIds);
        return items.stream()
          .sorted(Comparator.comparing(Item::getName))
          .collect(Collectors.toList());
    }

}

We want our code to depend on an abstraction, rather than a specific implementation. That’s why we use an interface. This can have many different implementations. For example, we could read items from a file, create an HTTP client to external service, or read the data from a database.

In this code, we’ll need to stub the external dependency, because we only want to test our logic contained in the getAllItemsSortedByName method.

4.2. Using a Stubbed Object in the Code Under Test

Let’s initialize the ItemService object in the setup() method using a Stub for the ItemProvider dependency:

ItemProvider itemProvider
ItemService itemService

def setup() {
    itemProvider = Stub(ItemProvider)
    itemService = new ItemService(itemProvider)
}

Now, let’s make itemProvider return a list of items on every invocation with the specific argument:

itemProvider.getItems(['offer-id', 'offer-id-2']) >> 
  [new Item('offer-id-2', 'Zname'), new Item('offer-id', 'Aname')]

We use >> operand to stub the method. The getItems method will always return a list of two items when called with [‘offer-id’, ‘offer-id-2’] list. [] is a Groovy shortcut for creating lists.

Here’s the whole test method:

def 'should return items sorted by name'() {
    given:
    def ids = ['offer-id', 'offer-id-2']
    itemProvider.getItems(ids) >> [new Item('offer-id-2', 'Zname'), new Item('offer-id', 'Aname')]

    when:
    List<Item> items = itemService.getAllItemsSortedByName(ids)

    then:
    items.collect { it.name } == ['Aname', 'Zname']
}

There are many more stubbing capabilities we can use, such as: using argument matching constraints, using sequences of values in stubs, defining different behavior in certain conditions, and chaining method responses.

5. Mocking Class Methods

Now, let’s talk about mocking classes or interfaces in Spock.

Sometimes, we would like to know if some method of the dependent object was called with specified arguments. We want to focus on the behavior of the objects and explore how they interact by looking on the method calls. Mocking is a description of mandatory interaction between the objects in the test class.

We’ll test the interactions in the example code we’ve described below.

5.1. Code with Interaction

For a simple example, we’re going to save items in the database. After success, we want to publish an event on the message broker about new items in our system.

The example message broker is a RabbitMQ or Kafka, so generally, we’ll just describe our contract:

public interface EventPublisher {
    void publish(String addedOfferId);
}

Our test method will save non-empty items in the database and then publish the event. Saving item in the database is irrelevant in our example, so we’ll just put a comment:

void saveItems(List<String> itemIds) {
    List<String> notEmptyOfferIds = itemIds.stream()
      .filter(itemId -> !itemId.isEmpty())
      .collect(Collectors.toList());
        
    // save in database

    notEmptyOfferIds.forEach(eventPublisher::publish);
}

5.2. Verifying Interaction with Mocked Objects

Now, let’s test the interaction in our code.

First, we need to mock EventPublisher in our setup() method. So basically, we create a new instance field and mock it by using Mock(Class) function:

class ItemServiceTest extends Specification {

    ItemProvider itemProvider
    ItemService itemService
    EventPublisher eventPublisher

    def setup() {
        itemProvider = Stub(ItemProvider)
        eventPublisher = Mock(EventPublisher)
        itemService = new ItemService(itemProvider, eventPublisher)
}

Now, we can write our test method. We’ll pass 3 Strings: ”, ‘a’, ‘b’ and we expect that our eventPublisher will publish 2 events with ‘a’ and ‘b’ Strings:

def 'should publish events about new non-empty saved offers'() {
    given:
    def offerIds = ['', 'a', 'b']

    when:
    itemService.saveItems(offerIds)

    then:
    1 * eventPublisher.publish('a')
    1 * eventPublisher.publish('b')
}

Let’s take a closer look at our assertion in the final then section:

1 * eventPublisher.publish('a')

We expect that itemService will call an eventPublisher.publish(String) with ‘a’ as the argument.

In stubbing, we’ve talked about argument constraints. Same rules apply to mocks. We can verify that eventPublisher.publish(String) was called twice with any non-null and non-empty argument:

2 * eventPublisher.publish({ it != null && !it.isEmpty() })

5.3. Combining Mocking and Stubbing

In Spock, a Mock may behave the same as a Stub. So we can say to mocked objects that, for a given method call, it should return the given data.

Let’s override an ItemProvider with Mock(Class) and create a new ItemService:

given:
itemProvider = Mock(ItemProvider)
itemProvider.getItems(['item-id']) >> [new Item('item-id', 'name')]
itemService = new ItemService(itemProvider, eventPublisher)

when:
def items = itemService.getAllItemsSortedByName(['item-id'])

then:
items == [new Item('item-id', 'name')]

We can rewrite the stubbing from the given section:

1 * itemProvider.getItems(['item-id']) >> [new Item('item-id', 'name')]

So generally, this line says: itemProvider.getItems will be called once with [‘item-‘id’] argument and return given array.

We already know that mocks can behave the same as stubs. All of the rules regarding argument constraints, returning multiple values, and side-effects also apply to Mock.

6. Spying Classes in Spock

Spies provide the ability to wrap an existing object. This means we can listen in on the conversation between the caller and the real object but retain the original object behavior. Basically, Spy delegates method calls to the original object.

In contrast to Mock and Stub, we can’t create a Spy on an interface. It wraps an actual object, so additionally, we will need to pass arguments for the constructor. Otherwise, the type’s default constructor will be invoked.

6.1. Code Under Test

Let’s create a simple implementation for EventPublisher. LoggingEventPublisher will print in the console the id of every added item. Here’s the interface method implementation:

@Override
public void publish(String addedOfferId) {
    System.out.println("I've published: " + addedOfferId);
}

6.2. Testing with Spy

We create spies similarly to mocks and stubs, by using the Spy(Class) method. LoggingEventPublisher does not have any other class dependencies, so we don’t have to pass constructor args:

eventPublisher = Spy(LoggingEventPublisher)

Now, let’s test our spy. We need a new instance of ItemService with our spied object:

given:
eventPublisher = Spy(LoggingEventPublisher)
itemService = new ItemService(itemProvider, eventPublisher)

when:
itemService.saveItems(['item-id'])

then:
1 * eventPublisher.publish('item-id')

We verified that the eventPublisher.publish method was called only once. Additionally, the method call was passed to the real object, so we’ll see the output of println in the console:

I've published: item-id

Note that when we use stub on a method of Spy, then it won’t call the real object method. Generally, we should avoid using spies. If we have to do it, maybe we should rearrange the code under specification?

7. Good Unit Tests

Let’s end with a quick summary of how the use of mocked objects improves our tests:

• we create deterministic test suites
• we won’t have any side effects
• our unit tests will be very fast
• we can focus on the logic contained in a single Java class
• our tests are independent of the environment

8. Conclusion

In this article, we thoroughly described spies, mocks, and stubs in Groovy. Knowledge on this subject will make our tests faster, more reliable, and easier to read.

The implementation of all our examples can be found in the Github project.