{"id":44886,"date":"2015-11-15T15:21:47","date_gmt":"2015-11-15T13:21:47","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=44886"},"modified":"2023-12-13T11:06:36","modified_gmt":"2023-12-13T09:06:36","slug":"getting-started-with-mockito","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2015\/11\/getting-started-with-mockito.html","title":{"rendered":"Getting started with Mockito"},"content":{"rendered":"

This article is part of our Academy Course titled Testing with Mockito<\/a>.<\/p>\n

In this course, you will dive into the magic of Mockito. You will learn about Mocks, Spies and Partial Mocks, and their corresponding Stubbing behaviour. You will also see the process of Verification with Test Doubles and Object Matchers. Finally, Test Driven Development (TDD) with Mockito is discussed in order to see how this library fits in the concept of TDD. Check it out here<\/a>!<\/em><\/p>\n

\n

Table of Contents<\/h4>\n
\n
1. Why Mock?<\/a><\/dt>\n
2. Introduction to the Mockito Framework<\/a><\/dt>\n
\n
\n
2.1. A Quick Example of Stubbing<\/a><\/dt>\n
2.2. A Quick Example of Verification<\/a><\/dt>\n<\/dl>\n<\/dd>\n
3. Mixing up a Mockito<\/a><\/dt>\n
4. Using Mockito with JUnit<\/a><\/dt>\n
5. Mockito Best Practices<\/a><\/dt>\n<\/dl>\n<\/div>\n

In this tutorial we are going to look at the Mockito Mocking Framework and prepare an Eclipse project to use it by adding it to the classpath.<\/p>\n

<\/a>1. Why Mock?<\/h2>\n

All of the code we write has a network of interdependencies, it may call into the methods of several other classes which in turn may call yet other methods; indeed this is the intent and power of object oriented programming. Usually at the same time as writing our feature code we will also write test code in the form of automated unit tests. We use these unit tests to verify the behaviour of our code, to ensure that it behaves as we expect it to behave.<\/p>\n

When we unit test our code we want to test it in isolation and we want to test it fast. For the purposes of the unit test we only care about verifying our own code, in the current class under test. Generally we also want to execute our unit tests very regularly, perhaps more than several times per hour when we are refactoring and we are working in our continuous integration environment.<\/p>\n

This is when all our interdependencies become an issue. We might end up executing code in another class that has a bug that causes our unit test to fail. Imagine a class which we use to read user details from a database, what happens if there\u2019s no database present when we want to run our unit tests? Imagine a class which calls several remote web services, what if they\u2019re down or take a long time to respond? Our unit tests could fail due to our dependencies and not because of some issue with the behaviour of our code. This is undesirable.<\/p>\n

In addition to this, it might be very difficult to force a specific event or error condition that we want to ensure our code handles correctly. What if we want to test that some class which deserializes an object handles a possible ObjectStreamException properly? What if we want to test all boundary return values from a collaborator? What about ensuring that some calculated value is passed correctly to a collaborator? It might take a lot of coding and a long time to replicate the conditions for our tests, if it is even possible at all.<\/p>\n

All these issues simply disappear if we use mocks. Mocks act like a substitute for the classes with which we are collaborating, they take their place and behave exactly how we tell them to behave. Mocks let us pretend that our real collaborators are there, even though they aren\u2019t. More importantly mocks can be programmed to return whatever values we want and confirm whatever values are passed to them. Mocks execute instantly and don\u2019t require any external resources. Mocks will return what we tell them to return, throw whatever exceptions we want them to throw and will do these things over and over, on demand. They let us test only the behaviour of our own code, to ensure that our class works, regardless of the behaviour of its collaborators.<\/p>\n

There are several mocking frameworks available for Java, each have their own syntax, their own strengths, their own weaknesses. In this tutorial we will be using the Mockito framework, which is one of the more popular mocking frameworks available.<\/p>\n

<\/a>2. Introduction to the Mockito Framework<\/h2>\n

Mockito is a Mocking Framework that makes it very easy to create mocks for the classes and interfaces with which your class under test interacts. Mockito provides a very simple API for creating mocks and assigning their behaviour. It allows you to very quickly specify expected behaviour and verify interactions with your mocks.<\/p>\n

Mockito has essentially two phases, one or both of which are executed as part of unit tests:<\/p>\n