{"id":43154,"date":"2019-01-09T06:51:31","date_gmt":"2019-01-09T06:51:31","guid":{"rendered":"https:\/\/www.softwaretestinghelp.com\/?page_id=43154"},"modified":"2025-04-01T08:07:16","modified_gmt":"2025-04-01T08:07:16","slug":"mockito-tutorial","status":"publish","type":"page","link":"https:\/\/www.softwaretestinghelp.com\/mockito-tutorial\/","title":{"rendered":"Mockito Tutorial: Mockito Framework for Mocking in Unit Testing"},"content":{"rendered":"

A Complete Guide to Mockito Framework: Hands-on Mockito Tutorials
\n<\/strong><\/p>\n

Unit testing is a simple yet effective technique to gain a good level of confidence in the code that is to be shipped.<\/p>\n

Moreover, it avoids regression issues with every piece of code that gets checked in.<\/p>\n

With micro-services kind of architecture (and even for simple structure involving basic database calls), straightforward unit testing does not suffice. What we need is to mock the dependencies and test the actual logic of the method under test.<\/p>\n

<\/strong><\/em><\/p>\n

\"Mockito<\/a><\/p>\n

List of ALL Mockito Tutorials in this Series:<\/strong><\/span><\/p>\n

Tutorial #1:<\/strong><\/span> Mockito Framework for Mocking in Unit Testing<\/a> (This Tutorial)
\nTutorial #2:<\/strong><\/span> Creating Mocks and Spies in Mockito<\/a>
\nTutorial #3:<\/strong><\/span> Different Types of Matchers Provided by Mockito<\/a>
\nTutorial #4:<\/strong><\/span> Mocking Private, Static and Void Methods Using Mockito<\/a>
\nTutorial #5:<\/strong><\/span> Top 12 Mockito Interview Questions<\/a><\/p>\n

**********************************************************************<\/p>\n

Overview of Tutorials in this Mockito Series<\/strong><\/span><\/p>\n\n

\n\n\n\n\t\n\n\t\n\t\n\t\n\t\n\t
Tutorial #<\/th>What You Will Learn<\/th>\n<\/tr>\n<\/thead>\n
Tutorial #1:<\/strong><\/td>Mockito Framework for Mocking in Unit Testing<\/a><\/strong>
\n
\nLearn mocking with Mockito - A comprehensive Mockito Tutorial for beginners with code examples. Learn Mocking Framework for Mocking in Unit Testing.<\/td>\n<\/tr>\n
Tutorial #2:<\/strong><\/td>Creating Mocks and Spies in Mockito<\/a><\/strong>
\n
\nMocks and Spies are types of test doubles, which are helpful in writing unit tests. Both are explained in this Mockito Spy tutorial with code examples.<\/td>\n<\/tr>\n
Tutorial #3:<\/strong><\/td>Different Types of Matchers Provided by Mockito<\/a><\/strong>
\n
\nLearn how to use different types of matchers provided by Mockito. Matchers are like wildcards where instead of a specific input\/output, you specify a range of input. Argument and Verification are the two types of Matchers in Mockito which are explained in detail here.<\/td>\n<\/tr>\n
Tutorial #4:<\/strong><\/td>Mocking Private, Static and Void Methods Using Mockito<\/a><\/strong>
\n
\nLearn Mocking Private, Static and Void methods in Mockito with Examples. Learn Mocking private and static methods by unit testing framework PowerMockito.<\/td>\n<\/tr>\n
Tutorial #5:<\/strong><\/td>Top 12 Mockito Interview Questions<\/a><\/strong>
\n
\nMockito Interview Questions and answers with sample code examples. This will help you to crack any Mockito Mocking Framework interview successfully.
\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n\n

Let’s start with the first tutorial in this series!!<\/strong><\/em><\/p>\n

Mocking in Unit testing<\/h3>\n

Mocks\/Stubs is a term that people commonly hear while creating unit tests in particular.<\/p>\n

So, what essentially is Mocking?<\/strong> In simple terms, it’s nothing but providing a controlled instance or implementation of dependency that the code under test depends on in order to test its core logic.<\/p>\n

The reason I mentioned it as a controlled instance is that the behavior of the dependency can be programmed or controlled as desired for the method or system under test.<\/p>\n

To explain it diagrammatically, let\u2019s take an example of any Business or Ecommerce Application. Almost every such type of application primarily has 3 layers i.e. User Interface, Business Layer & Data Access layer<\/strong> (which talks to the underlying data store)<\/p>\n

\"Example:<\/p>\n

Referring to the above diagram, Business Layer has 3 dependencies namely i.e. Data Access Layer and 2 other services which are Service 1 and Service 2.<\/p>\n

Look at it this way \u2013 An app like google maps can have dependencies on an<\/strong><\/p>\n

    \n
  1. Actual data stores like MySQL or any other no SQL database which stores Map data.<\/li>\n
  2. An external service like CoordinateService which provides latitudes and longitudes of a location.<\/li>\n
  3. An external service like traffic service which provides real-time traffic information for a given Coordinate pair.<\/li>\n<\/ol>\n

    So, if someone is trying to validate the core business logic using unit test, until and unless they have working implementations of these dependencies, the tests could not be run.<\/p>\n

    Mocks come to rescue in these situations, where no matter your dependency is up and running or not, you are always guaranteed to run your business logic with a programmed response for the dependency that\u2019s being getting called from the code under test.<\/p>\n

    Types\/Categories of Test Doubles<\/h3>\n

    Mock is essentially a type of \u201cTest Double\u201d \u2013 it\u2019s a tech jargon. \u201cTest Double\u201d essentially means an object which is replaced by equivalent real object instance or dependency.<\/p>\n

    There are different types of Test doubles as mentioned below:<\/strong><\/p>\n

    #1) Fakes:<\/span><\/h4>\n

    A fake is a working implementation similar to a real dependency, except the fact that it is local to the system under test.<\/p>\n

    Example:<\/strong><\/span> Instead of hitting a real production DB, the test uses a simple collection\/in-memory to store data.<\/p>\n

    \"Type<\/p>\n

    #2) Stubs:<\/span><\/h4>\n

    Stubs are pre-configured responses when a dependency is called from the system under test.<\/p>\n

    \"Type<\/p>\n

    #3) Spies:\u00a0<\/span><\/h4>\n

    As the name suggests, its actually the real function (dependency) call with some watching mechanism. Post the call, it can be verified whether the call was actually triggered or not along with the parameters.<\/p>\n

    \"Type<\/p>\n

    #4) Mocks:\u00a0<\/span><\/h4>\n

    Mocks are special instances of objects, on which Stubbed\/pre-configured responses can be specified. The fact that the mock got called can be verified as an assert in the test.<\/p>\n

    For Example:<\/strong> <\/span><\/p>\n

    There is a report generator function which sends an email to a specified address during execution.<\/p>\n

    As we don\u2019t want to send actual email, again and again,\u00a0during testing, the EmailService is mocked (and the email method which sends the email is configured to do nothing when it\u2019s called). At the end of the test, we can just verify that the email sending method of the email service got called through the mocked object.<\/p>\n

    Different Mocking Frameworks<\/h3>\n

    Almost all the languages provide different kinds of mocking frameworks. We will be writing a sample code using Mockito which is an open source Mocking framework for Java.<\/p>\n

    Anatomy of a simple unit test with mocked dependency. Suppose, we are trying to unit test an application which calculates total marks for a student in all the subjects and writes it to DB.<\/p>\n

    \r\npublic void calculateSumAndStore(String studentId, int[] scores)\r\n {\r\n    int total = 0;\r\n    for (int score: scores) {\r\n        total = total + score;\r\n    } \/\/ write total to DB\r\n    databaseImpl.updateScores(studentId, total);\r\n  }  \r\n\r\n<\/pre>\n
    Now if we want to write a unit test for the method \u2013 calculateSumAndStore , then we might not be having a real implementation of a database to store the total. In that case, we won\u2019t ever be able to unit test this function.<\/p>\n
    But with mocks in place, we can simply pass a Mock for database service and validate the rest of the logic<\/p>\n
    Sample test as shown below:<\/strong><\/span><\/p>\n
    \r\n@Test\r\npublic void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb()\r\n {\r\n   \/\/ Arrange\r\n    studentScores = new StudentScoreUpdates(mockDatabase);\r\n    int[] scores = {  60, 70, 90  };\r\n    Mockito.doNothing().when(mockDatabase).updateScores("student1", 220); \r\n\r\n    \/\/ Act\r\n    studentScores.calculateSumAndStore("student1", scores); \r\n\r\n    \/\/ Assert\r\n    Mockito.verify(mockDatabase, Mockito.times(1)).updateScores("student1", 220);\r\n}\r\n<\/pre>\n
    We seen in the above test, we have provided a mockDatabase object to the parent class (for the method under test) and we\u2019ve set up a stub response for the mockedDatabase object \u2013 Line#6 above (Mockito.doNothing().when(mockDatabase).updateScores(“student1”,\u00a0220);)<\/strong><\/p>\n
    The important points to note from the above are:<\/strong><\/p>\n
    #1)<\/strong> The mocked object need to setup stubbed responses for all the methods that will be called during the function execution.<\/p>\n
    #2)<\/strong> The parameters specified during stub creation can be specific or generic.<\/p>\n
    Example<\/strong><\/span> in the above case \u2013 we have specified the parameters for the updateScores method as \u201cstudent1\u201d and 220 because we know that these are the exact inputs with which our method is going to be called.<\/p>\n
    #3) During verification, we are validating the following:<\/strong><\/p>\n