Mastering Mocking with @Mock and @InjectMocks

1. The "Why": From Manual Instantiation to Declarative Mocks

In the previous lesson, we immediately used annotations. But to appreciate their value, let's see what they replace. Without annotations, you would have to create and manage mocks manually in every test or in a setup method.

For example, to create a mock UserRepository, you would write:

UserRepository userRepository = Mockito.mock(UserRepository.class);

While this works, it can become repetitive and verbose as you add more dependencies. The @Mock annotation is a more declarative and readable way to achieve the same result.

@Mock
private UserRepository userRepository;

This tells Mockito, "I want a mock object for this field." Mockito then handles the creation for us. This approach has several advantages that contribute to better tests in the long run.

For these annotations to work, we need to tell Mockito to process them. As we've seen, @ExtendWith(MockitoExtension.class) is the standard way to do this in JUnit 5. It acts as the engine that finds and initializes all the fields annotated with @Mock, @InjectMocks, etc., before our tests run.

2. The "How": A Practical Look at Injecting Mocks

Simply creating a mock with @Mock is only half the story. The real goal is to get that mock object inside the service instance we are testing. This is the job of @InjectMocks.

Let's walk through a common scenario step-by-step to see why @InjectMocks is so critical. The following video provides an excellent, practical demonstration.

As you saw in the video, the annotations work in tandem:

1. @ExtendWith(MockitoExtension.class) activates Mockito.
2. @Mock creates mock instances of your dependencies (e.g., ProductRepository).
3. @InjectMocks creates a real instance of your class under test (e.g., ProductService) and scans for dependencies it can fulfill using the created mocks.

3. Understanding Injection Strategies

So, how does @InjectMocks decide where to put the mocks? It's not magic. Mockito uses a specific order of strategies to perform the injection:

1. Constructor Injection: Mockito looks for the "greediest" constructor (the one with the most parameters) it can satisfy with the available mocks. If it finds one, it will instantiate your class using that constructor, passing the mocks as arguments.
2. Setter Injection: If constructor injection fails (e.g., there's no suitable constructor or only a no-arg constructor), Mockito will then look for setter methods that match the types of your mocks. For a field named userRepository, it would look for a setUserRepository(...) method.
3. Field Injection: If neither of the above works, Mockito will attempt to inject the mocks directly into the fields, even if they are private.

Constructor injection is the preferred method in modern software design because it makes dependencies explicit and allows for creating immutable objects. By designing your services to take their dependencies in the constructor, you make your code clearer and your tests more straightforward.

Here's an example of a test setup that relies on constructor injection:

// The service we want to test
@Service
public class OrderService {
    private final ProductRepository productRepository;
    private final NotificationService notificationService;

    // Constructor injection
    public OrderService(ProductRepository productRepository, NotificationService notificationService) {
        this.productRepository = productRepository;
        this.notificationService = notificationService;
    }

    // ... business logic
}

// The test class
@ExtendWith(MockitoExtension.class)
class OrderServiceTest {

    @Mock
    private ProductRepository productRepository; // Mock dependency 1

    @Mock
    private NotificationService notificationService; // Mock dependency 2

    @InjectMocks
    private OrderService orderService; // Mockito will create an OrderService and inject the two mocks via the constructor.

    @Test
    void testPlaceOrder() {
        // ... Arrange, Act, Assert
    }
}

@ExtendWith(MockitoExtension.class)
class PaymentServiceTest {

    @Mock
    private PaymentGateway paymentGateway;

    @Mock
    private FraudDetector fraudDetector;

    @InjectMocks
    private PaymentService paymentService;

    // ... your test methods
}

Conclusion

In this lesson, we took a much deeper look into the mechanics of mocking with annotations. You now understand not just what @Mock and @InjectMocks do, but also why they are beneficial and how they work together to create an isolated testing environment for your service layer.

Key Takeaways:

• Mockito annotations like @Mock and @InjectMocks significantly reduce boilerplate code and improve the readability of your tests.
• Annotations must be initialized. For JUnit 5, @ExtendWith(MockitoExtension.class) is the standard mechanism.
• @InjectMocks intelligently injects fields annotated with @Mock into your class under test.
• Mockito prioritizes constructor injection, falling back to setter and then field injection. Aligning your code with constructor injection is a best practice.

What's Next?

We've now thoroughly covered how to unit test the service layer in isolation. But a backend application has multiple layers. In our next lesson, "Write integration tests for the web layer using @WebMvcTest and MockMvc," we will move up the stack. You'll learn how to test your REST controllers, which handle incoming HTTP requests. We will see how the skills you've just mastered—mocking dependencies—are essential for testing the web layer without needing a running service layer.