Partial Method Mocking with Mockito: A Comprehensive Guide to Selective Method Simulation

Concept and Requirements of Partial Method Mocking

In software testing practice, we often encounter situations where we need to mock only some methods in a class rather than all methods. This requirement is particularly common when testing complex business logic, especially when certain methods depend on external resources or have side effects, while other methods need to maintain their original implementation to ensure test accuracy.

Implementation Approaches for Partial Mocking in Mockito

Mockito provides multiple approaches to implement partial method mocking, each with specific application scenarios and considerations.

Using mock with thenCallRealMethod()

The most direct approach for partial mocking is through mock objects combined with thenCallRealMethod(). In this mode, all methods are mocked by default, and only methods explicitly specified to call real methods will execute their original implementation.

// Create mock object
Stock stock = mock(Stock.class);

// Set mocked method return values
when(stock.getPrice()).thenReturn(100.00);
when(stock.getQuantity()).thenReturn(200);

// Specify calling real method
when(stock.getValue()).thenCallRealMethod();

The advantage of this approach is fine-grained control, allowing explicit specification of each method's behavior. However, it's important to note that if the class under test contains complex constructors or initialization logic, additional configuration may be required.

Using spy Objects for Partial Mocking

Spy objects provide another implementation approach for partial mocking. Unlike mocks, spies use real method implementations by default, and only explicitly mocked methods return preset values.

// Create spy object
Stock stock = spy(Stock.class);

// Use doReturn to avoid real method invocation
doReturn(100.00).when(stock).getPrice();
doReturn(200).when(stock).getQuantity();

There's an important consideration when using spies: if using the when().thenReturn() syntax, the real method will be executed when when() is called, which may cause unexpected side effects. Therefore, it's recommended to use the doReturn().when() syntax to avoid this issue.

Using CALLS_REAL_METHODS Parameter

Mockito also provides the CALLS_REAL_METHODS parameter, which can create mock objects that call real methods by default.

Stock MOCK_STOCK = Mockito.mock(Stock.class, CALLS_REAL_METHODS);

This approach is suitable for scenarios where most methods need real implementations and only a few methods require mocking. However, it's important to note that if mocked methods depend on other mocked methods, additional configuration may be necessary.

Practical Case Analysis

Considering the testing scenario for the Stock class: we need to mock the getPrice() and getQuantity() methods to control test inputs, while simultaneously ensuring that the getValue() method executes the real multiplication calculation logic.

public class Stock {
    private final double price;
    private final int quantity;

    Stock(double price, int quantity) {
        this.price = price;
        this.quantity = quantity;
    }

    public double getPrice() {
        return price;
    }

    public int getQuantity() {
        return quantity;
    }

    public double getValue() {
        return getPrice() * getQuantity();
    }
}

In this case, using the spy approach is the most appropriate choice because the getValue() method depends on the return values of getPrice() and getQuantity(). By mocking these two methods, we can precisely control test inputs while maintaining the real calculation logic of getValue().

Common Pitfalls and Solutions

Spy Object Initialization Issues

When using spies, if the class under test has complex constructors or initialization logic, problems may arise. Solutions include:

• Using @Spy annotation with @ExtendWith(MockitoExtension.class)
• Manually creating object instances and then wrapping with spy()
• Using Answer to implement complex initialization logic

Method Dependency Issues

In partial mocking, if real methods depend on mocked methods, it's essential to ensure the correct order of mock setup. It's generally recommended to set up all mocks first before executing test logic.

Performance Considerations

Partial mocking incurs some performance overhead compared to full mocking, particularly in frequently called test scenarios. For performance-sensitive applications, consider using other testing strategies.

Alternative Approaches and Best Practices

Avoiding Mocking Altogether

In some simple scenarios, completely avoiding mocking might be a better choice:

@Test
public void getValueTest() {
    Stock stock = new Stock(100.00, 200);
    double value = stock.getValue();
    assertEquals("Stock value not correct", 100.00*200, value, .00001);
}

This approach is straightforward and simple, avoiding the complexity of mocking frameworks, and is suitable for testing scenarios with simple logic.

Designing Testable Code

From a code design perspective, good design can reduce the need for partial mocking:

• Follow the Single Responsibility Principle
• Use dependency injection
• Break down complex logic into small, independently testable methods
• Apply the Interface Segregation Principle

Conclusion

Mockito's partial method mocking functionality provides powerful support for complex testing scenarios. By appropriately choosing between mock, spy, or CALLS_REAL_METHODS, developers can precisely control the testing environment while maintaining the authenticity of critical business logic. In practical applications, it's recommended to select the most suitable mocking strategy based on specific requirements and be mindful of avoiding common pitfalls. Good code design and testing strategies are equally important, as they can reduce the need for complex mocking and improve test reliability and maintainability.