15.7. Using Mockito

@Mock
Service mockService;

In this chunk, we learn how to create mocks using Mockito. The @Mock annotation is a convenient way to tell Mockito that we want to create a mock object of the Service class. When this annotation is applied, Mockito generates a fake instance of Service that we can use in our tests instead of the real one. This helps us isolate the test to focus on the class being tested without involving its dependencies.

Imagine you are conducting an experiment but can’t access the actual equipment. Instead, you use a model that mimics how the actual equipment works. This model allows you to test your theories without the complexities of the real thing, just like a mock allows you to test your code without the dependencies.

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

In this chunk, we learn how to specify the behavior of our mock object. The when(...).thenReturn(...) approach is used to tell Mockito what to do when a specific method is called on the mock. In this case, whenever getData() is called on mockService, it will return a predefined string: "Mocked Data". This is important for isolating tests because it allows control over the mock's responses without needing the actual implementation.

Think of this like a role-playing game where you have a character that responds to questions in a specific way. If someone asks this character their age, they always say '30'. Here, you are controlling the responses of the character (mock) in your game (test) to suit your testing needs.

@InjectMocks
Controller controller;

This chunk introduces the @InjectMocks annotation, which is used to create and inject the mock objects into the class that we are testing. In this example, it indicates that the Controller class we are testing will automatically receive the mocked Service object as a dependency. This allows tests to focus on the class under test while using controlled mock objects for its dependencies.

Imagine you are a chef who uses a special mixer to prepare your dishes. Instead of creating a new mixer every time, you have a dedicated one that is perfect for all your recipes. @InjectMocks is like that dedicated mixer—it provides the expected tools with no extra fuss, so the chef (controller) can create great meals (perform its functions) without worrying about finding the right mixer each time.

verify(mockService).getData();

In this chunk, we learn about the verification aspect of Mockito. The verify(...) method is used to check that a particular method was called on our mock object. In this specific case, we are confirming that the getData() method of mockService was indeed called during the execution of our test. This is crucial for ensuring the behavior of our code meets expectations and that the interactions with dependencies are as intended.

Think of a teacher giving a quiz and then checking if all the students raised their hands when asked if they understand the material. By verifying that the students acknowledged, the teacher knows that the information was communicated effectively. Similarly, verify acts like that teacher, confirming the interactions between your code and its dependencies.

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 section gives a complete example of using Mockito to create a unit test. Here, we are defining a test class, ServiceTest, with a method testServiceLogic. We create a mock of DataRepository, specify that when getName() is called, it returns 'Mocked Name'. Then, we create an instance of Service, passing in our mocked repository. Finally, we assert that calling getName() on the service returns the expected mocked name. This showcases how mocks can simplify testing by removing the need for a real database or repository call.

Imagine you need to test a delivery process but don't have the actual delivery truck available. Instead, you create a toy model that represents the truck. You can simulate sending a package and see if it corrects the destination based on all the rules you've set. With mocks, you can handle the logic without the real thing, ensuring that your delivery system behaves as expected even when the actual truck isn't present.

--