Stubs, mocks or virtual assets?

If, during the software development process, you stumble upon the need to access software components that:

  • Have not yet been developed,
  • Do not contain sufficient test data,
  • Require access fees, or
  • Are otherwise constrained with regards to accessibility,

there are several options you may consider to work around this issue. In this post, I will introduce three options and explain some of the most important of their characteristics.

Please note that the terms ‘stub’ and ‘mock’ are often mixed up in practice, so what is defined as a mock here might be called a stub somewhere else and vice versa. However, I tried to use definitions that are more or less agreed upon in the development and testing community.

The simplest form of removing dependency constraints is the use of stubs. A stub is a very simple placeholder that does pretty much nothing besides replacing another component. It provides no intelligence, no data driven functionality and no validations. It can be created quickly and is most commonly used by developers to mimick behaviour of objects and components not available in their development environment.

Mocks contain a little more intelligence compared to stubs. They are commonly configured to be used for specific test or development purposes. They are used to define and verify expectations with regards to behaviour. For example, a mock service might be configured to always return certain test data in response to a request recevied, so that specific test cases can be executed by testers. The difference between mocks and stubs from a testing perspective can be summarized by the fact that a mock can cause a test case to fail, whereas a stub can’t.

Virtual assets
Virtual assets are simulated components that closely mimic the behaviour of ‘the real thing’. They can take a wide variety of inputs and return responses that their real-life counterpart would return too. They come with data driven capabilities that allow responses (and therefore behaviour) to be configured on the fly, even by people without programming knowledge. Virtual assets should also replicate connectivity to the simulated component by applying the same protocols (JMS, HTTP, etc.) and security configuration (certificates, etc.). The application of virtual assets in test environments is commonly called service virtualization.

Testing terms related to stubs and mocks

If you want to read more about component or API stubbing, mocking or virtualization, this page in the SmartBear API Testing Dojo provides an interesting read. Also, Martin Fowler wrote a great piece on mocks and stubs on his blog back in 2007.

Up and running with: Mockito

This is the third article in our series on new, popular or otherwise interesting tools used in test automation. You can read all posts within this series by clicking here.

What is Mockito?
Mockito is an open source testing framework for Java that allows developers to create mock objects for use in automated unit tests. It is often used in the Test Driven Development and Behavior Driven Development approaches. Using Mockito mock objects, developers can mock external dependencies and ensure their code interacts with it in the expected manner.

Where can I get Mockito?
Mockito can be downloaded from this site.

How do I install and configure Mockito?
As the Mockito framework consists of just a single .jar file, all you need to do is to add this .jar as a dependency to your Java project and you’re ready to start mocking!

Creating a first Mockito mock object
Before we can start creating mock objects using Mockito, we first need a Java class for which we can mock the behavior. To illustrate the workings of Mockito I created a simple class Login, consisting of a single constructor, two String variables username and password and a single method login(username,password). The class implementation is included in the download link at the end of this post.

Now, assume that this Login class is either not readily available when you want to perform unit tests that have this class as a dependency, or that you want to emulate a certain type of behavior. To do so, let’s create a Mockito mock for the Login class:

public static Login createLoginMock() {

	// create and return a mock instance of the Login class	
	return mock(Login.class);

Easy, right? Now, let’s see what we can do with this mock.

Using your Mockito mock
First, let’s check whether we can interact with the methods of our mock correctly. Mockito provides a verify function for this:

public static void runVerifyTestWithMockito() {
	// create mock instance of the login class
	Login loginMock = createLoginMock();
	// call methods on the mock instance
	// verify that methods are called properly
	// attempt to verify a method that hasn't been called (this generates an error)

The last call generated an error, as we try to verify an interaction that hasn’t taken place.

Now, let’s use Mockito to stub the behavior of a method of the Login class, so that we can use our mock to simulate specific behavior in our unit tests. In Mockito, this is done using a when … thenReturn … construction:

public static void runStubTestWithMockito() {
	// create mock instance of the login class
	Login loginMock = createLoginMock();
	// stub mock behavior
	// call mock method and verify result

Finally, we can also have a class method of our mock return an exception, even when the actual class implementation might not always do that. This is useful when testing exception handling in your code and is done using a when … thenThrow … construction:

public static void runExceptionTestWithMockito() {

	// create mock instance of the login class
	Login loginMock = createLoginMock();

	// have the mock return an Exception
	when(loginMock.getPassword()).thenThrow(new RuntimeException());

	// call the mock method that throws the exception

Useful features
I’ve showed you some of the basic features of Mockito. However, the framework offers loads more, such as:

  • Verification that a method is invoked exactly once / at least x times / never / …
  • Verification that methods are invoked in a particular order
  • Explicitly verify that certain mock classes have not been interacted with

An extensive list of Mockito features, along with examples, can be found here.

Further reading
There is a lot of documentation to be found on Mockito on the web, apart from the reading material which I’ve linked to above. For example, a nice tutorial, including using Mockito for Android testing, can be found on the site of Lars Vogel. For those that prefer actual books, Tomek Kaczanowski has written a book on Mockito and TestNG, which can be purchased here.

An Eclipse project including my Login class implementation and the tests I’ve demonstrated above can be downloaded here.

Happy mocking!