This article aims to solve the problem that the stub method is not executed as expected when using Mockito spy. The core reason is that production code directly instantiates dependencies rather than using spy objects created in tests. The article will elaborate on this common misunderstanding in detail and provide a solution to decoupling through dependency injection, thereby effectively improving the testability and modularity of the code.

Problem analysis: Common misunderstandings in Mockito Spy

In unit tests, Mockito's spy function allows us to partially simulate a real object, that is, we can call methods of real objects, or stub or verify specific methods. However, a common misconception is that when production code (i.e. the code being tested) directly creates an instance of the object it depends on, the spy object created in the test will not take effect.

Consider the following production code snippet where the MyService class creates an instance of GetOptionBidPrice directly:

 // Production code public class MyService {
    public double calculateBidPrice() {
        // The problem lies: MyService directly instantiates GetOptionBidPrice internally
        GetOptionBidPrice getOptionBidPrice = new GetOptionBidPrice(/* construct parameter*/);
        double bidPrice = getOptionBidPrice.getBidPrice();
        return bidPrice;
    }
}

// Depended public class GetOptionBidPrice {
    // Suppose there is a constructor and getBidPrice method public GetOptionBidPrice(/* constructor parameters*/) {
        // ... Initialization...
    }

    public double getBidPrice() {
        // Real business logic, which may return 0.0 or other default value return 0.0;
    }
}

When trying to test MyService, we might write test code like this, trying to stubble the getBidPrice method:

 // Test code (Error demonstration)
import org.junit.jupiter.api.Test;
import static org.mockito.Mockito.*;

public class MyServiceTest {

    @Test
    void testCalculateBidPriceWithSpy() {
        // 1. Create MyService instance MyService myService = new MyService();

        // 2. Create a spy object of GetOptionBidPrice and stake it.// Note: the spyGetOptionBidPrice created here is an independent instance GetOptionBidPrice spyGetOptionBidPrice = spy(new GetOptionBidPrice(/* construct parameter */));
        doReturn(100.0).when(spyGetOptionBidPrice).getBidPrice();

        // 3. Call MyService method double result = myService.calculateBidPrice();

        // The expected result is 100.0, but the actual result will be 0.0
        // Because myService creates a brand new GetOptionBidPrice instance inside, instead of our staked spyGetOptionBidPrice
        System.out.println("Actual result: " result); // Output 0.0
        // assertEquals(100.0, result); // Assertion failed}
}

The root of the problem: The problem with the above test code is that when the calculateBidPrice method inside MyService is executed, a brand new GetOptionBidPrice instance will be recreated through the new GetOptionBidPrice() statement. This new instance is two completely different objects from the spyGetOptionBidPrice instance we created and staked in our tests. Therefore, the getBidPrice() method called internally by MyService is the real method of the new instance, rather than the method that is piled on the spy object, causing the piled operation to fail to take effect.

Solution: Embrace dependency injection

The core idea of solving this problem is to separate the creation and management of dependent objects from the dependent classes, so that the dependent classes are no longer directly responsible for creating their dependencies. This design pattern is called Dependency Injection (DI) . Through dependency injection, we can inject a spy or mock object during testing and the real object in production environment.

There are many ways to implement dependency injection, the most common are constructor injection and method injection .

1. Constructor Injection

This is the most recommended method, especially for mandatory dependencies. The dependent object receives all its dependencies when constructed.

Renovated production code:

 // Production code (using constructor injection)
public class MyService {
    private final GetOptionBidPrice getOptionBidPrice;

    // Dependency injects public MyService(GetOptionBidPrice getOptionBidPrice) {
        this.getOptionBidPrice = getOptionBidPrice;
    }

    public double calculateBidPrice() {
        // MyService now uses the injected GetOptionBidPrice instance return getOptionBidPrice.getBidPrice();
    }
}

Renovated test code:

 // Test code (using constructor injection)
import org.junit.jupiter.api.Test;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.assertEquals;

public class MyServiceTest {

    @Test
    void testCalculateBidPriceWithInjectedSpy() {
        // 1. Create a spy object of GetOptionBidPrice and stake its method GetOptionBidPrice spyGetOptionBidPrice = spy(new GetOptionBidPrice(/* construct parameter*/));
        doReturn(100.0).when(spyGetOptionBidPrice).getBidPrice();

        // 2. Inject spy objects into MyService instance MyService myService = new MyService(spyGetOptionBidPrice);

        // 3. Call MyService method double result = myService.calculateBidPrice();

        // Now, MyService internally calls the getBidPrice() method of the spy object we injected assertEquals(100.0, result);
        verify(spyGetOptionBidPrice).getBidPrice(); // Verify whether the method is called}
}

2. Method injection

If the dependency is not required for every operation, or needs to be provided when a specific method is executed, method injection can be used.

Renovated production code:

 // Production code (using method injection)
public class MyService {
    public double calculateBidPrice(GetOptionBidPrice getOptionBidPrice) {
        // Dependency is used to inject return getOptionBidPrice.getBidPrice() through method parameter;
    }
}

Renovated test code:

 // Test code (using method injection)
import org.junit.jupiter.api.Test;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.assertEquals;

public class MyServiceTest {

    @Test
    void testCalculateBidPriceWithMethodInjectedSpy() {
        // 1. Create a spy object of GetOptionBidPrice and stake its method GetOptionBidPrice spyGetOptionBidPrice = spy(new GetOptionBidPrice(/* construct parameter*/));
        doReturn(100.0).when(spyGetOptionBidPrice).getBidPrice();

        // 2. Create MyService instance MyService myService = new MyService();

        // 3. When calling the MyService method, pass the spy object as a parameter into double result = myService.calculateBidPrice(spyGetOptionBidPrice);

        assertEquals(100.0, result);
        verify(spyGetOptionBidPrice).getBidPrice();
    }
}

Advantages of Dependency Injection

In addition to solving the problem that spy does not take effect, dependency injection also brings many benefits:

• Improve testability: The dependencies between modules are clear, making it easy to replace with mock or spy objects in the test, thereby isolating the test scope and real unit testing.
• Reduce coupling: Objects are no longer directly responsible for creating and managing their dependencies, but are provided by external (such as IoC containers or test code), making coupling between modules less and easier to maintain and modify.
• Improve code maintainability and scalability: When dependencies change, you only need to modify the injection point without modifying the creation logic inside the dependency class. This makes the system easier to adapt to changes in demand.
• Better code structure: Force developers to think about dependencies between modules, helping to design clearer and more consistent with the principle of single responsibility.

Summary and best practices

When you find that the stake or simulated behavior fails to perform as expected when using Mockito's spy or mock function, one of the primary troubleshooting directions is to check whether your production code directly instantiates its dependencies. If so, then dependency injection is the key to solving this problem.

Key points:

• Avoid direct new dependency objects inside the tested class.
• Preference is given to using constructor injection to deal with mandatory dependencies.
• Consider using method injection to handle optional or context-dependent dependencies.
• Using Mockito's @InjectMocks and @Mock/@Spy annotations can simplify the test code, and Mockito will try to inject dependencies automatically.

By adopting the dependency injection mode, it can not only effectively solve the problem of using Mockito spy, but also fundamentally improve the quality, testability and maintainability of the code. It is an indispensable design practice in modern software development.

The above is the detailed content of Solve that the Mockito Spy method is not called: Deep parsing and dependency injection practice. For more information, please follow other related articles on the PHP Chinese website!