15.7.2. Mocking Behavior

@Mock
Service mockService;

In this chunk, we learn how to create a mock object using the @Mock annotation. Mock objects are substitutes for real objects and are used in testing to simulate the behavior of complex dependencies. The @Mock annotation indicates that mockService is a mock version of the Service class, which allows us to define specific behaviors for it without the overhead of using a real instance.

Imagine if you were trying to test a car’s navigation system, but the car was in the shop. Instead of taking it out and risking delays, you can use a toy car that mimics the navigation interface. This way, you can still test how the navigation system reacts when you input different destinations, just like using a mock object in our tests.

when(mockService.getData()).thenReturn("Mocked Data");

This chunk demonstrates how to specify the behavior of a mock object using Mockito. The when(...).thenReturn(...) syntax sets up the expectation that when mockService.getData() is called, it should return the string "Mocked Data". This allows us to control the output of the getData() method, making our tests predictable and reliable.

Think of this like creating a script for an actor in a play. If you tell the actor (the mock object) that whenever they’re asked to say a line (method call), they should respond with a certain phrase (mocked return value). This way, you can ensure the scene plays out exactly how you want it every time, just like controlling the output of a mocked method.

@InjectMocks
Controller controller;

This chunk introduces the @InjectMocks annotation, which is used to inject mock objects into the class under test. In this case, the mockService will be injected into the Controller instance. This allows us to test the Controller class with the predefined behavior of mockService, ensuring our tests focus on the behavior of Controller while relying on controlled mock dependencies.

Imagine a chef in a kitchen who needs specific ingredients (mock objects) to prepare a dish. By using @InjectMocks, the ingredients are automatically provided to the chef (Controller), allowing them to create their meal (perform operations) without getting distracted by how those ingredients were sourced (mock dependency behavior).

verify(mockService).getData();

In this chunk, we see how to verify that a certain behavior occurred on a mock object using the verify method. By calling verify(mockService).getData(), we are checking if the method getData() on mockService was invoked during the test. This is crucial in confirming that our Controller is correctly interacting with its dependencies.

Consider a teacher checking if a student followed instructions during a class exercise. The teacher can ask if the student completed a specific task (calling the method) to ensure that they were listening and engaged. Similarly, using the verify method confirms whether the mock behavior was acted upon as expected during the test.

import org.junit.jupiter.api.Test;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.*;
public class ServiceTest {
@Test
void testServiceLogic() {
DataRepository mockRepo = mock(DataRepository.class);
when(mockRepo.getName()).thenReturn("Mocked Name");
Service service = new Service(mockRepo);
assertEquals("Mocked Name", service.getName());
}
}

This chunk presents a complete example of using Mockito in a test case. We create a mock object for DataRepository, set its behavior to return a specific string when getName() is called, and inject it into a Service instance. We then assert that the name returned by the service matches what we expected. This showcases how mocking can help isolate a unit of code while ensuring it interacts correctly with its dependencies.

Think of this like a chef relying on a sous-chef to always pass them a specific ingredient. The chef can confidently prepare their dish, knowing that every time they request that ingredient (method call), they get exactly what they want (mocked return value). This process allows us to validate the chef's (Service's) cooking (logic) without being affected by the actual sourcing of the ingredient (DataRepository).

--