What is a Stub Object?

In the realm of unit testing, Mockito stands as one of the most popular mocking frameworks within the Java ecosystem. Its core value lies in its ability to precisely control the execution environment of the code under test. Among these capabilities, "Stubbing" (or Stubs/Pillars) serves as the cornerstone for achieving this goal. Simply put, a Stub is a mechanism or behavioral pattern that allows testers to dynamically define the behavior and response of a specific object at runtime. This enables the isolation of external dependencies, ensuring the independence and reliability of unit tests.
In traditional programming development, when we invoke a method, we typically expect it to return a specific result based on established business logic. However, during unit testing, we often cannot control the implementation details of real objects (such as database queries, network requests, or interactions with complex third-party libraries). Introducing Mockito's Stubbing functionality effectively "fakes" the behavior of these external dependencies.

The primary purposes of Stubs include:

Isolating Dependencies: Decouple the class under test from complex external systems to ensure tests focus solely on the business logic itself.
Verifying Expected Behavior: Quickly verify whether input parameters correctly trigger expected output results by predefining return value rules.
Simplifying Test Scenarios: Simulate various boundary conditions and exception states (such as null pointers or timeouts) without requiring real data.

How to Use Mockito for Stubbing

Creating a Stub object using Mockito typically involves two core steps: first, creating a Mock object instance, and second, setting return values for specific method calls on that object. This process is known as "Stubbing" or "Pillaring".

1. Basic Usage Example

Assume we have a simple service class UserService that depends on a real UserRepository to retrieve user data. In unit testing, we can use Mockito to create a Mock object for UserRepository and set the return value of its query method.

import org.junit.jupiter.api.Test;
import static org.mockito.Mockito.*;

// Define the dependency interface and the real service class (implementation omitted)
interface UserRepository {
    User findById(Long id);
}

class UserService {
    private final UserRepository repository;
    
    public UserService(UserRepository repo) {
        this.repository = repo;
    }
    
    @Test
    void testFindUserById() {
        // Step 1: Create a Mock object (this is the carrier for Stubs)
        UserRepository mockRepo = mock(UserRepository.class);

        // Step 2: Set return values (core Stubbing operation)
        User expectedUser = new User(1L, "Alice");
        when(mockRepo.findById(1L)).thenReturn(expectedUser);

        // Execute the logic under test
        UserService userService = new UserService(mockRepo);
        User result = userService.findUserById(1L);

        // Assert that the result matches expectations
        assertEquals(expectedUser, result);
    }
}

In the code above, the combination of when(...).thenReturn(...) represents a typical Stubbing operation. It instructs Mockito: "When findById is called with the argument 1L, please return the expectedUser object I specified." Without this rule, Mockito would default to throwing an exception or returning null, allowing the test to capture whether the actual logic behaves as expected.

2. Advanced Stubbing Scenarios: Verification and Multi-Condition Matching

Beyond simple fixed return values, Stubbing can handle more complex business logic requirements, such as determining return values based on combinations of multiple parameters, or executing different operation chains under specific conditions.

Multi-Parameter Matching: If a method signature includes multiple variables, Mockito supports precisely specifying all parameter combinations via when(obj.method(arg1, arg2)).

when(mockRepo.findById(1L)).thenReturn(new User(1L));
when(mockRepo.findById(2L)).thenThrow(new IllegalArgumentException("User not found"));
// Calls that do not match any rule will throw an exception unless thenAnswer() is used.

Dynamic Logic Responses: Using thenAnswer() allows passing a Lambda expression or function object to write custom logic. This is very useful when handling complex business rules (such as returning different discount strategies based on amount ranges).
```
when(mockRepo.findById(anyLong()))
    .thenAnswer(invocation -> {
        Long id = invocation.getArgument(0);
        if (id > 100) return new User(id, "VIP");
        else return null;
    });
```

Collaboration Between Stubbing and Verification

Stubbing does not exist in isolation; it is usually complementary to another major feature of Mockito—Verification. In testing, we care not only about whether a method returns the correct value (via Stubbing) but also confirm that the method was indeed called, along with the number of times and correctness of parameters.

For example, we can first use when to set return values and then use verify to check invocation details:

// ... previous code remains unchanged ...
UserService userService = new UserService(mockRepo);
userService.findUserById(1L); // Execute logic

// Verify that mockRepo.findById(1L) was indeed called
verify(mockRepo).findById(eq(1L));

Summary and Best Practices

Stubbing is a tool that empowers developers with powerful control within the Mockito framework. It allows us to construct a controllable, predictable world in the testing environment, thereby focusing on verifying the correctness of core business logic. In practical application, it is recommended to follow these principles:

Clear Intent: Every Stub rule should clearly express the expected behavior of "if input X, then output Y".
Avoid Over-Reliance: Although Mockito is powerful, it should not be abused to mask design flaws in the code (such as high cohesion and low coupling). Good architecture itself should minimize reliance on complex external objects.
Use with Verification: Stubbing defines "what should happen," while Verification confirms "that it did happen." Only when combined do they form a complete testing loop.

By mastering the use of Stub objects, developers can write more robust, maintainable, and regression-friendly unit test code, significantly improving software development efficiency and quality.