15.7.1. Creating Mocks

@Mock
Service mockService;

In order to create a mock object in Mockito, you utilize the @Mock annotation. This annotation tells Mockito to generate a mock instance of the specified class, in this case, Service. This mock can then be used in tests as a substitute for a real Service object, allowing you to control its behavior during testing without requiring an actual implementation.

Think of creating a mock like hiring an actor for a role in a play without actually using a real character. Just as the actor can perform actions and say lines as if they are that character, the mock can mimic the Service class's behavior in your tests. This allows you to check how your application reacts without needing the actual Service to be present.

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

The when(...).thenReturn(...) construct is used to define the behavior of the mocked object, mockService. Here, when the method getData() is called on mockService, instead of executing its actual logic, it returns the string "Mocked Data". This allows you to test what happens when getData() provides that specific output.

Imagine you are testing a phone's contact app, and instead of inserting real contact names, you use a mock contact that always returns 'John Doe' whenever its name is requested. This simplifies testing without needing actual contacts, just like the mocked behavior allows testing without invoking real service logic.

@InjectMocks
Controller controller;

The @InjectMocks annotation is used to create an instance of the class under test (in this case, Controller) while also injecting any mock objects into it. Mockito will automatically look for any dependencies of the Controller class and inject the corresponding mocked dependencies, like mockService, helping to isolate the functionality of Controller during testing.

Think of @InjectMocks like assembling a toy set where certain pieces need to come together to function properly. Here, Controller is the complete toy, and the mocks act as the necessary pieces that fit together, allowing you to see how the toy works without requiring the real, often complex, components.

verify(mockService).getData();

The verify(...) method checks whether a certain method on the mock object was executed. In this case, it confirms that getData() was indeed called on mockService. This verification is crucial for ensuring that your tests are not only running correctly but also that the interactions with the mocked dependencies occur as expected during the test.

Imagine you are checking off items on a grocery list after shopping. If you verify that you have picked up milk, you are confirming that the interaction took place. Similarly, verify acts as your checklist to ensure that mockService was used as expected when you tested your Controller.

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());
}
}

In this example, a test class named ServiceTest uses a mock of DataRepository. Here, mock(DataRepository.class) creates the mock, and the when(...).thenReturn(...) Stub is used to specify that getName() should return "Mocked Name". The Service class is then tested by checking if it correctly returns the mocked name using assertEquals(...), which compares the expected output with the actual output of service.getName().

Think of this example like a student practicing for a science fair presentation by using a peer to simulate asking questions about their project. Just as the peer (mock) provides prepared responses to help the student prepare, the mock DataRepository provides predictable data to help test the Service class effectively.

--