Configuring Mockito Mock Objects to Return Different Values on Consecutive Calls

Problem Background and Root Cause Analysis

In unit testing practice, developers frequently encounter scenarios where mock objects need to return different values across various test cases. As demonstrated in the provided example code, when using @BeforeClass annotation and static variables, the mock object's behavior persists between test cases, causing subsequent tests to fail behaving as expected.

The core issue lies in the violation of test isolation principles. The JUnit framework executes test methods in an undetermined order, while static variables maintain their state throughout the test class lifecycle. This means that configurations applied to mock objects in the first test affect all subsequent tests, compromising test independence and repeatability.

Optimal Solution Analysis

According to the best answer recommendation, the correct approach is to change mock object declaration from static variables to instance variables, and use @Before annotation instead of @BeforeClass. This ensures that mock objects are reinitialized before each test method execution, maintaining test environment isolation.

class TestClass {
    private Foo mockFoo;
    
    @Before
    public void setUp() {
        mockFoo = mock(Foo.class);
    }
    
    @Test
    public void test1() {
        when(mockFoo.someMethod()).thenReturn(0);
        TestObject testObj = new TestObject(mockFoo);
        assertEquals(0, testObj.bar());
    }
    
    @Test
    public void test2() {
        when(mockFoo.someMethod()).thenReturn(1);
        TestObject testObj = new TestObject(mockFoo);
        assertEquals(1, testObj.bar());
    }
}

Advanced Techniques for Consecutive Call Variations

For scenarios requiring mock objects to return different values on multiple calls within a single test method, Mockito provides chained thenReturn methods. This approach is particularly useful for testing state machines, iterators, or scenarios requiring specific call sequences.

@Test
public void testConsecutiveCalls() {
    when(mockFoo.someMethod())
        .thenReturn(0)
        .thenReturn(1)
        .thenReturn(-1);
    
    TestObject testObj = new TestObject(mockFoo);
    
    // First call returns 0
    assertEquals(0, testObj.bar());
    
    // Second call returns 1
    assertEquals(1, testObj.bar());
    
    // Third and subsequent calls return -1
    assertEquals(-1, testObj.bar());
    assertEquals(-1, testObj.bar());
}

Mockito also supports varargs syntax for simplified consecutive call configuration:

when(mockFoo.someMethod()).thenReturn(0, 1, -1);

Performance Considerations and Best Practices

Although using @Before annotation means mock objects are recreated before each test method, potentially raising performance concerns, this overhead is generally acceptable. Modern Mockito frameworks have minimal mock object creation costs, and the benefits of test isolation far outweigh this minor performance impact.

From a system design perspective, this pattern embodies the single responsibility principle and dependency injection concepts. By independently configuring mock objects in each test, we ensure test atomicity and maintainability. When tests fail, problems can be quickly identified without interference from other tests.

Practical Application Scenarios Extension

This technique finds extensive application in real-world projects. For instance, when testing database operations, different query results can be mocked; when testing network requests, various response states can be simulated; when testing business logic, different external service behaviors can be emulated.

It's crucial to understand that good test design should follow the FIRST principles: Fast, Independent, Repeatable, Self-validating, and Timely. The solutions discussed in this article are concrete manifestations of these principles.