Unit Testing Your Methods By Mocking Private Methods With JMockit Library

So you wrote some public methods which in turn call other private methods and you are asked to write junits for those public methods. But your private method calls do stuffs that you don’t want to test (for example, they might be trying to connect to a database). How would you then write a unit test for you public methods at the same time avoid stuffs that are done in the private methods?

In this tutorial, I will show you how you can use JMockit to mock the private methods. The main magic is, when you are mocking a private method, do not write the access modifier (private).

So instead of trying to mock the method the following way,

@Mock
private boolean doPrivateStuff() {
}

Use this one instead – no private:

@Mock
boolean doPrivateStuff() {
}

Here is the complete code.

package com.kushal.tools;

import mockit.Mock;
import mockit.MockUp;

import org.hamcrest.CoreMatchers;
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;

/**
 * This class shows you how to Mock a private method.
 * @author Kushal Paudyal
 * www.sanjaal.com/java
 * www.icodejava.com
 *
 */

public class PrivateMethodMockTest {

    SomeClass object;
    @Before
    public void setup() {
        object = new SomeClass();
    }
    @SuppressWarnings("unused")
    @Test
    public void test_doPublicStuff_with_mocked_private_method() {
        new MockUp<SomeClass>() {
            @Mock
            boolean doPrivateStuff() {
                System.out.println("This is a mocked private method of class - SomeClass");
                
                /**
                 * Returning false from a mocked method
                 */
                return false; 
            }
        };
        
        boolean result = object.doPublicStuff();
        
        Assert.assertThat(result, CoreMatchers.is(false));
    }
    
    @Test
    public void test_doPublicStuff_with_no_mocking() {
        
        boolean result = object.doPublicStuff();
        
        Assert.assertThat(result, CoreMatchers.is(true));
    }
}

/**
 * This is a demo class whose public method will be tested.
 * Private method can be mocked.
 */
class SomeClass {
    
    public boolean doPublicStuff() {

        System.out.println("Inside doPublicStuff");
        /**
         * Call doPrivateStuff() method from this public method
         */
        return doPrivateStuff();
    }
    
    /**
     * Defining a private method that we want to mock with JMockit
     */
    private boolean doPrivateStuff() {
        System.out.println("Doing Some Private Stuff from Class - SomeClass");
        
        /**
         * Returning true from a real  method.
         */
        return true;
    }
    
}

Iterative development benefits in the Agile software development

Iterative Development in Agile Methodologies

Iterative Development in Agile Methodologies

As we know, the waterfall model of software engineering is getting obsolete day by day as more and more companies are choosing to go for the agile model of software development where they have seen lots of solid benefits by trying the agile and experimenting with variations of it to fit their own need. Agile is not rigid set of rules, although there are guiding principles.

So what are the benefits of using the iterative development also called sprints in Agile? Here are a few that I can think of.

  1. Iterative development in agile has a continuous focus on improving the processes.
  2. Iterative development pays attention to the quality of work, learning from what went bad and what things went good in prior iterations.
  3. Iterative development can help align or modify the priorities based on the outcome of the previous iteration deliveries.
  4. Business priorities and the business values can change all the time. Iterative development helps to adjust those values and priorities.
  5. With iterative development, the estimates get better as we grow. This estimate will be close to reality than the waterfall model of development where the estimations are done at the beginning of the project, which might not hold true as the project progresses.
  6. In the iterative development, there is opportunity to build the highest risk items first.
  7. Iterative development allows the testing to occur early and often.
  8. Iterative development allows to deliver the product early and deliver often.
  9. Risk discover, risk analysis and risk mitigation can occur earlier.
  10. Allows us to change the software even in the late cycle of development.
  11.  Because of the splitting of the task, the complexity in the iterations are manageable.
  12.  Iterative development helps produce early parrtial product which in turn can obtain early feedback and changes.
  13. With the continuous delivery and continous feedback, the final product becomes more closer to what user needs.
  14. Iterative development enforces better communication and engagement.
  15. Time boxed iterations give an idea of when to expect the delivery.