{"id":3881,"date":"2025-07-08T13:04:04","date_gmt":"2025-07-08T10:04:04","guid":{"rendered":"https:\/\/www.certbolt.com\/certification\/?p=3881"},"modified":"2025-12-30T14:51:31","modified_gmt":"2025-12-30T11:51:31","slug":"mastering-unit-testing-in-java-a-comprehensive-guide-to-mockito-annotations-and-core-mocking-techniques","status":"publish","type":"post","link":"https:\/\/www.certbolt.com\/certification\/mastering-unit-testing-in-java-a-comprehensive-guide-to-mockito-annotations-and-core-mocking-techniques\/","title":{"rendered":"Mastering Unit Testing in Java: A Comprehensive Guide to Mockito Annotations and Core Mocking Techniques"},"content":{"rendered":"

In the dynamic landscape of modern software development, robust unit testing is not merely a best practice; it is an indispensable cornerstone for constructing resilient, maintainable, and high-quality applications. Unit tests play a pivotal role in isolating individual components of a codebase, validating their behavior in isolation, and ensuring that changes or refactorings do not inadvertently introduce regressions. Within the Java ecosystem, Mockito stands out as an exceptionally powerful and intuitive mocking framework, empowering developers to create sophisticated, readable, and highly effective unit tests. This detailed exposition will embark on a thorough exploration of Mockito’s core functionalities, with a particular emphasis on its convenient annotations (@Mock, @InjectMocks, and @Spy) and the fundamental techniques for crafting mock objects, defining their expected behaviors, and meticulously verifying interactions within test scenarios. By delving into these crucial aspects, this guide aims to equip developers with the comprehensive knowledge required to elevate their unit testing prowess and foster greater confidence in their Java applications.<\/span><\/p>\n

Streamlining Test Setup: Demystifying Mockito Annotations<\/b><\/p>\n

Mockito annotations represent a highly convenient and declarative approach to the creation and systematic management of mock objects within your test suites. They significantly simplify the often tedious process of manually configuring dependencies and injecting them into the specific class or component under scrutiny during testing. By leveraging these annotations, developers can achieve cleaner, more concise test code, thereby enhancing readability and reducing boilerplate. This section will meticulously dissect the functionalities and practical applications of three pivotal Mockito annotations: @Mock, @InjectMocks, and @Spy.<\/span><\/p>\n

The @Mock Annotation: Crafting Simulated Dependencies<\/b><\/p>\n

The @Mock annotation is a fundamental construct in Mockito, serving the primary purpose of instantiating a mock object for a specified class or interface. When a field within a test class is adorned with @Mock, Mockito intelligently intercepts this declaration during test execution setup. It then proceeds to generate a proxy object that meticulously mimics the external behavior of the real object, yet without invoking any of its actual, underlying implementations. This simulation capability is precisely what empowers developers to isolate the code being tested from its intricate dependencies, ensuring that the unit under examination performs as expected regardless of the complexities or potential side effects of its collaborating components. Utilizing @Mock allows for precise control over the environment surrounding the unit test, enabling the simulation of various scenarios, including error conditions, specific return values, or method call sequences, all without relying on the actual, potentially heavy or external, implementations of those dependencies.<\/span><\/p>\n

Consider the following illustrative example demonstrating the efficacious use of @Mock:<\/span><\/p>\n

Java<\/span><\/p>\n

import org.junit.runner.RunWith;<\/span><\/p>\n

import org.mockito.Mock;<\/span><\/p>\n

import org.mockito.junit.MockitoJUnitRunner;<\/span><\/p>\n

@RunWith(MockitoJUnitRunner.class)<\/span><\/p>\n

public class MyServiceTest {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@Mock<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0private DataRepository mockRepository; \/\/ Mock object for DataRepository<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ Further test methods would utilize mockRepository to define behavior<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ and verify interactions.<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ Example of a test method structure<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ @Test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ public void testRetrieveData() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Arrange: Define behavior of mockRepository<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 Mockito.when(mockRepository.findById(1L)).thenReturn(new SomeData(1L, «Test Data»));<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Act: Call the method on the class under test (which would use mockRepository)<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ MyService myService = new MyService(mockRepository); \/\/ Assuming MyService depends on DataRepository<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ SomeData retrievedData = myService.retrieve(1L);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Assert: Verify the outcome and interactions<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Assertions.assertNotNull(retrievedData);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Assertions.assertEquals(«Test Data», retrievedData.getName());<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Mockito.verify(mockRepository).findById(1L);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ }<\/span><\/p>\n

}<\/span><\/p>\n

In the preceding code snippet, by simply annotating mockRepository with @Mock, Mockito gracefully intervenes to create a mock instance of the DataRepository interface. This newly minted mock object then becomes available for stubbing its methods (i.e., defining what values they should return when called) and verifying subsequent interactions (i.e., asserting that specific methods were indeed invoked with the expected arguments) within the encompassing test cases. This declarative approach significantly reduces the manual setup required, leading to cleaner and more maintainable test code.<\/span><\/p>\n

The @InjectMocks Annotation: Automating Dependency Injection<\/b><\/p>\n

The @InjectMocks annotation stands as a remarkable convenience feature within Mockito, designed to automate the often-cumbersome process of injecting mock objects into the very class that is the subject of the current unit test. Its primary utility lies in streamlining the setup of the test environment by intelligently wiring the previously created mock objects (those annotated with @Mock or @Spy) into the dependencies of the class being tested. This automatic injection capability liberates developers from the necessity of manually instantiating dependencies and then passing them through constructors or setters, thereby significantly reducing boilerplate code and enhancing the overall fluidity of test development.<\/span><\/p>\n

Consider the following illustrative example demonstrating the elegant application of @InjectMocks:<\/span><\/p>\n

Java<\/span><\/p>\n

import org.junit.runner.RunWith;<\/span><\/p>\n

import org.mockito.InjectMocks;<\/span><\/p>\n

import org.mockito.Mock;<\/span><\/p>\n

import org.mockito.junit.MockitoJUnitRunner;<\/span><\/p>\n

@RunWith(MockitoJUnitRunner.class)<\/span><\/p>\n

public class OrderProcessorTest {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@Mock<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0private PaymentGateway mockPaymentGateway; \/\/ A mock dependency for processing payments<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@Mock<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0private InventoryService mockInventoryService; \/\/ Another mock dependency for managing stock<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@InjectMocks<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0private OrderProcessor orderProcessor; \/\/ The class under test, whose dependencies will be injected<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ Example of a test method structure<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ @Test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ public void testProcessOrderSuccessfully() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Arrange: Stub behaviors of mock dependencies<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 Mockito.when(mockPaymentGateway.processPayment(Mockito.anyDouble())).thenReturn(true);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 Mockito.when(mockInventoryService.deductStock(Mockito.anyString(), Mockito.anyInt())).thenReturn(true);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Act: Invoke the method on the class under test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 boolean result = orderProcessor.processOrder(«productA», 2, 100.0);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Assert: Verify the outcome and interactions<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Assertions.assertTrue(result);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Mockito.verify(mockPaymentGateway).processPayment(100.0);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Mockito.verify(mockInventoryService).deductStock(«productA», 2);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ }<\/span><\/p>\n

}<\/span><\/p>\n

In this expanded illustration, both mockPaymentGateway and mockInventoryService are declared as mock objects using @Mock. Crucially, the orderProcessor instance, representing the OrderProcessor class (which is the actual component we intend to unit test), is marked with @InjectMocks. During the test setup phase, Mockito proactively identifies the necessary dependencies for OrderProcessor (likely through its constructor or setter methods) and intelligently injects the corresponding mock instances (mockPaymentGateway and mockInventoryService) into it. This automated dependency wiring allows developers to focus exclusively on testing the intrinsic behavior and business logic of OrderProcessor, obviating the need for manual dependency instantiation and configuration, thereby fostering a cleaner and more efficient test development workflow.<\/span><\/p>\n

The @Spy Annotation: Embracing Partial Mocking<\/b><\/p>\n

The @Spy annotation in Mockito introduces the powerful concept of partial mocking, offering a nuanced approach to test isolation. Unlike @Mock, which creates a complete substitute for an object, @Spy is designed to wrap an <\/span>actual, real instance<\/span><\/i> of a class. This means that when you invoke a method on a spy object, by default, its original, concrete implementation is executed. However, the true strength of @Spy lies in its ability to selectively override or stub specific methods of that real object. This selective stubbing allows you to retain the authentic behavior for most methods while precisely controlling the outcome of particular methods as needed for your test scenario. This hybrid approach is particularly useful when dealing with legacy codebases or complex objects where only a handful of methods require controlled simulation, and the default behavior of others is perfectly acceptable.<\/span><\/p>\n

Consider the following example demonstrating the judicious application of @Spy:<\/span><\/p>\n

Java<\/span><\/p>\n

import org.junit.runner.RunWith;<\/span><\/p>\n

import org.mockito.Mockito;<\/span><\/p>\n

import org.mockito.Spy;<\/span><\/p>\n

import org.mockito.junit.MockitoJUnitRunner;<\/span><\/p>\n

@RunWith(MockitoJUnitRunner.class)<\/span><\/p>\n

public class ReportingServiceTest {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ A real instance of ReportGenerator, which will be spied upon<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@Spy<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0private ReportGenerator realReportGenerator = new ReportGenerator();<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ Example of a test method structure<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ @Test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ public void testGenerateReportWithCustomHeader() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Arrange: Stub a specific method on the spy while retaining others<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 Mockito.when(realReportGenerator.generateHeader()).thenReturn(«Custom Report Header»);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Act: Invoke the method on the spy (other methods will execute real logic)<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 String fullReport = realReportGenerator.generateFullReport(); \/\/ Assume this internally calls generateHeader() and other real methods<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Assert: Verify the outcome and interactions<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Assertions.assertTrue(fullReport.contains(«Custom Report Header»));<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Mockito.verify(realReportGenerator).generateHeader(); \/\/ Verify the stubbed method was called<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Mockito.verify(realReportGenerator).generateFooter(); \/\/ Verify a non-stubbed real method was called<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ }<\/span><\/p>\n

}<\/span><\/p>\n

In this illustration, realReportGenerator is annotated with @Spy and initialized with a genuine instance of ReportGenerator. This configuration permits Mockito to create a spy object that wraps someObject. You can then proceed to selectively stub or verify specific methods of realReportGenerator (e.g., generateHeader()) while all other methods will seamlessly execute their original, actual implementations. This offers a potent blend of real object behavior and mock-like control, making @Spy an invaluable tool for targeted testing and interaction verification without resorting to full-blown mocking when only partial control is necessary.<\/span><\/p>\n

The Art of Substitution: Methodologies for Creating Mock Objects with Mockito<\/b><\/p>\n

Mock objects are an essential facet of isolating the specific component under scrutiny during unit testing, providing a controlled environment to meticulously verify its behavior in isolation. Mockito, with its elegant and versatile API, offers a variety of methods for the instantiation of these simulated dependencies, accommodating diverse testing requirements and coding styles. This section will delve into the various techniques available for generating mock objects using Mockito, ensuring that developers can select the most appropriate approach for their given test scenario.<\/span><\/p>\n

Leveraging the @Mock Annotation for Declarative Mock Creation<\/b><\/p>\n

As elaborated previously, the @Mock annotation stands as one of the most convenient and widely adopted mechanisms for creating mock objects in Mockito. When a field within your test class is adorned with this annotation, Mockito automatically undertakes the responsibility of instantiating a mock object for the corresponding class or interface during the test setup phase. This declarative style not only reduces the amount of boilerplate code required but also enhances the readability of your test classes, clearly signaling which dependencies are being mocked.<\/span><\/p>\n

Consider its straightforward application:<\/span><\/p>\n

Java<\/span><\/p>\n

import org.junit.runner.RunWith;<\/span><\/p>\n

import org.mockito.Mock;<\/span><\/p>\n

import org.mockito.junit.MockitoJUnitRunner;<\/span><\/p>\n

@RunWith(MockitoJUnitRunner.class)<\/span><\/p>\n

public class ProductServiceTest {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@Mock<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0private ProductRepository productDataRepository; \/\/ Mock object for the ProductRepository interface<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ Example test method showing how productDataRepository would be used<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ @Test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ public void testGetProductById() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Arrange: Define behavior for the mock repository<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 Product dummyProduct = new Product(«Laptop», 1200.0);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 Mockito.when(productDataRepository.findById(«123»)).thenReturn(dummyProduct);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Act: Assuming ProductService uses productDataRepository<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ ProductService service = new ProductService(productDataRepository);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Product retrievedProduct = service.getProductDetails(«123»);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Assert: Verify the outcome<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Assertions.assertNotNull(retrievedProduct);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Assertions.assertEquals(«Laptop», retrievedProduct.getName());<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ \u00a0 \u00a0 \/\/ Mockito.verify(productDataRepository).findById(«123»);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\/\/ }<\/span><\/p>\n

}<\/span><\/p>\n

In the aforementioned example, the inclusion of @Mock on the productDataRepository field prompts Mockito to generate a mock instance of the ProductRepository interface. This mock object is then readily available for defining method stubs (i.e., specifying what values its methods should return when invoked) and for subsequently verifying interactions with it during the execution of your test cases. This method is particularly favored in test frameworks like JUnit where @RunWith(MockitoJUnitRunner.class) or MockitoAnnotations.openMocks(this) can be used to process these annotations automatically.<\/span><\/p>\n

Employing the Mockito.mock() Method for Programmatic Mocking<\/b><\/p>\n

Beyond annotations, Mockito also provides a direct, programmatic approach to creating mock objects through its static Mockito.mock() method. This method offers greater flexibility, especially in scenarios where annotation-based setup might be less convenient or when mocks need to be created dynamically within a method rather than as class fields. The Mockito.mock() method accepts the Class or Interface type for which a mock is desired and returns a fully functional mock object of that type.<\/span><\/p>\n

Consider the following example illustrating the direct usage of Mockito.mock():<\/span><\/p>\n

Java<\/span><\/p>\n

import org.junit.jupiter.api.BeforeEach;<\/span><\/p>\n

import org.junit.jupiter.api.Test;<\/span><\/p>\n

import org.mockito.Mockito;<\/span><\/p>\n

import static org.junit.jupiter.api.Assertions.assertEquals;<\/span><\/p>\n

public class UserServiceTest {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0private UserRepository mockUserRepository; \/\/ Declared without @Mock for manual creation<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0private UserService userService; \/\/ The class under test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@BeforeEach<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0public void setup() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Manually create a mock object using Mockito.mock()<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0mockUserRepository = Mockito.mock(UserRepository.class);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Manually inject the mock into the UserService instance<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0userService = new UserService(mockUserRepository);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@Test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0public void testGetUserAccount() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Arrange: Define the behavior of the mock repository<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0User dummyUser = new User(«john.doe», «John Doe»);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Mockito.when(mockUserRepository.findByUsername(«john.doe»)).thenReturn(dummyUser);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Act: Invoke the method on the class under test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0User retrievedUser = userService.getUserAccount(«john.doe»);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Assert: Verify the outcome and interaction<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0assertEquals(«John Doe», retrievedUser.getFullName());<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Mockito.verify(mockUserRepository).findByUsername(«john.doe»);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

}<\/span><\/p>\n

In this demonstration, within the setup() method (annotated with JUnit’s @BeforeEach, ensuring it runs before each test), a mock object for the UserRepository interface is explicitly created by invoking Mockito.mock(UserRepository.class). This manually instantiated mock object is then assigned to the mockUserRepository field. This method grants fine-grained control over mock object creation and is particularly useful in test setups that do not use MockitoJUnitRunner or when mock instances need to be generated conditionally.<\/span><\/p>\n

Leveraging the Mockito.spy() Method for Partial Mocking<\/b><\/p>\n

The Mockito.spy() method provides a distinctive approach to mock creation, enabling the generation of partial mock objects. Unlike Mockito.mock() which creates an entirely simulated object, Mockito.spy() wraps an existing, real instance of an object. This unique capability means that by default, any method invoked on the spy object will execute its genuine, underlying implementation. However, the crucial advantage is that you retain the flexibility to selectively «stub» specific methods of this real object, overriding their natural behavior for the duration of the test. This is an invaluable technique when you need to test a class that has complex dependencies where only a few methods need to be controlled or when you are dealing with legacy code that is difficult to fully mock.<\/span><\/p>\n

Consider the following illustrative example of employing Mockito.spy():<\/span><\/p>\n

Java<\/span><\/p>\n

import org.junit.jupiter.api.BeforeEach;<\/span><\/p>\n

import org.junit.jupiter.api.Test;<\/span><\/p>\n

import org.mockito.Mockito;<\/span><\/p>\n

import static org.junit.jupiter.api.Assertions.assertEquals;<\/span><\/p>\n

public class DataTransformerTest {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0private DataTransformer transformer; \/\/ The real object to be spied on<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@BeforeEach<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0public void setup() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Create a real instance of DataTransformer<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0transformer = new DataTransformer();<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Create a spy object that wraps the real instance<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0transformer = Mockito.spy(transformer);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@Test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0public void testTransformWithSpecificValue() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Arrange: Stub one method to return a controlled value<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Mockito.when(transformer.calculateHash(«input»)).thenReturn(«customHashValue»);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Act: Invoke a method that might use the stubbed method internally<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0String processedData = transformer.processData(«input»); \/\/ Assume processData calls calculateHash<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Assert: Verify results and interactions<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0assertEquals(«processed_customHashValue», processedData); \/\/ Expected output if processData concatenates «processed_» with hash<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Mockito.verify(transformer).calculateHash(«input»); \/\/ Verify the stubbed method was called<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Mockito.verify(transformer, Mockito.times(1)).logOperation(); \/\/ Verify a real method was called once<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

}<\/span><\/p>\n

In this example, within the setup() method, a genuine instance of DataTransformer is first created. Subsequently, Mockito.spy(transformer) is invoked to produce a spy object that encapsulates this real instance, effectively allowing someObject to be both a real object and a mockable entity. This dynamic allows you to selectively override certain method behaviors for testing purposes (e.g., calculateHash()) while preserving the original functionality of all other methods (e.g., logOperation()). The Mockito.spy() method is particularly useful for fine-tuning test control, especially when a full mock might be overly restrictive or difficult to set up, providing a powerful middle ground for complex test scenarios.<\/span><\/p>\n

Defining Behavior: Stubbing Methods and Returning Expected Values<\/b><\/p>\n

Stubbing methods is a cornerstone feature of Mockito, providing the critical capability to explicitly define the behavior of mock objects when their methods are invoked during a test. Without stubbing, methods on mock objects typically return default values (e.g., null for objects, 0 for numeric primitives, false for booleans). By stubbing, you precisely specify what values or actions a mock object’s methods should yield, thereby creating a predictable and controlled environment for your unit tests. Mockito offers a highly fluent and readable API for stubbing, enabling developers to simulate various scenarios with ease. This section will explore the primary techniques for stubbing methods and dictating their return values.<\/span><\/p>\n

The thenReturn() Method: Specifying Direct Return Values<\/b><\/p>\n

The thenReturn() method is the most commonly used and straightforward way to stub a method call on a mock object. It allows you to specify a fixed value that the method should return when it is invoked. This is ideal for scenarios where the mock’s response is deterministic and independent of the arguments it receives (unless specific argument matchers are used).<\/span><\/p>\n

Its usage is highly intuitive:<\/span><\/p>\n

Java<\/span><\/p>\n

import org.junit.jupiter.api.Test;<\/span><\/p>\n

import org.mockito.Mockito;<\/span><\/p>\n

import static org.junit.jupiter.api.Assertions.assertEquals;<\/span><\/p>\n

public class ReportServiceTest {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@Test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0public void testGenerateSummaryReport() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 1. Create a mock object for the DataProcessor dependency<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0DataProcessor mockProcessor = Mockito.mock(DataProcessor.class);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 2. Stub the ‘process’ method on the mock:<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/\u00a0 \u00a0 When mockProcessor.process(«raw_data») is called, it should return «processed_data_summary»<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Mockito.when(mockProcessor.process(«raw_data»)).thenReturn(«processed_data_summary»);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 3. Create the class under test, injecting the mock dependency<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ReportService reportService = new ReportService(mockProcessor);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 4. Act: Invoke the method on the class under test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0String result = reportService.generateSummary(«raw_data»);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 5. Assert: Verify the outcome<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0assertEquals(«processed_data_summary», result);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Also verify that the process method was called on the mock<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Mockito.verify(mockProcessor).process(«raw_data»);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

}<\/span><\/p>\n

In this example, Mockito.when(mockProcessor.process(«raw_data»)).thenReturn(«processed_data_summary»); effectively instructs the mockProcessor object that whenever its process(«raw_data») method is invoked, it must return the literal string «processed_data_summary». This allows ReportService to proceed with its logic as if a real DataProcessor had returned that specific value.<\/span><\/p>\n

You can also chain multiple thenReturn() calls to define different return values for successive invocations of the same method:<\/span><\/p>\n

Java<\/span><\/p>\n

\/\/ First call returns «Value 1», second call returns «Value 2», subsequent calls return «Value 3»<\/span><\/p>\n

Mockito.when(mockDependency.getValue()).thenReturn(«Value 1»).thenReturn(«Value 2»).thenReturn(«Value 3»);<\/span><\/p>\n

This chaining is invaluable for testing scenarios where a mock’s behavior needs to evolve over multiple calls within a single test.<\/span><\/p>\n

The thenAnswer() Method: Dynamic and Conditional Behavior<\/b><\/p>\n

While thenReturn() is excellent for fixed return values, the thenAnswer() method provides a significantly more powerful and flexible mechanism for stubbing. It allows you to provide a custom implementation or logic that determines the return value (or even performs actions like throwing exceptions) based on the method’s arguments, the state of the mock, or any other dynamic factor. This method accepts an instance of the Answer functional interface (or a lambda expression that implements it), within which you can define the desired behavior.<\/span><\/p>\n

Its advanced usage is as follows:<\/span><\/p>\n

Java<\/span><\/p>\n

import org.junit.jupiter.api.Test;<\/span><\/p>\n

import org.mockito.Mockito;<\/span><\/p>\n

import org.mockito.invocation.InvocationOnMock;<\/span><\/p>\n

import org.mockito.stubbing.Answer;<\/span><\/p>\n

import static org.junit.jupiter.api.Assertions.assertEquals;<\/span><\/p>\n

public class CalculatorTest {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@Test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0public void testOperationWithDynamicResult() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 1. Create a mock object for the OperationExecutor dependency<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0OperationExecutor mockExecutor = Mockito.mock(OperationExecutor.class);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 2. Stub the ‘execute’ method using thenAnswer:<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/\u00a0 \u00a0 The return value will be dynamically calculated based on the arguments<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Mockito.when(mockExecutor.execute(Mockito.anyInt(), Mockito.anyInt(), Mockito.anyString()))<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0.thenAnswer(new Answer<Integer>() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0@Override<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0public Integer answer(InvocationOnMock invocation) throws Throwable {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0int arg1 = invocation.getArgument(0); \/\/ Get the first argument<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0int arg2 = invocation.getArgument(1); \/\/ Get the second argument<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0String operation = invocation.getArgument(2); \/\/ Get the third argument<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if («ADD».equals(operation)) {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return arg1 + arg2;<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} else if («MULTIPLY».equals(operation)) {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return arg1 * arg2;<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw new IllegalArgumentException(«Unknown operation: » + operation);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0});<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 3. Create the class under test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Calculator calculator = new Calculator(mockExecutor);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 4. Act and Assert for different scenarios<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0assertEquals(5, calculator.performCalculation(2, 3, «ADD»));<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0assertEquals(10, calculator.performCalculation(2, 5, «MULTIPLY»));<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Verify interactions<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Mockito.verify(mockExecutor).execute(2, 3, «ADD»);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Mockito.verify(mockExecutor).execute(2, 5, «MULTIPLY»);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

}<\/span><\/p>\n

In this expanded illustration, Mockito.when(mockExecutor.execute(…)).thenAnswer(…) provides a custom implementation for the execute() method. The lambda expression (or anonymous inner class implementing Answer) receives an InvocationOnMock object, which provides details about the method call (like arguments). This allows the stub to dynamically calculate and return «Dynamic value» or any other value based on the runtime context of the method invocation. thenAnswer() is incredibly powerful for simulating complex behaviors, callbacks, or when the return value depends directly on the input arguments in a non-trivial way.<\/span><\/p>\n

Other Stubbing Methods: thenThrow(), doNothing(), doReturn()<\/b><\/p>\n

Mockito offers a suite of other then… and do… methods for various stubbing needs:<\/span><\/p>\n

thenThrow(Throwable… throwables)<\/b>: Used to make a void method throw an exception or a non-void method throw an exception instead of returning a value.<\/span>
\n<\/span>Java<\/span>
\n<\/span>Mockito.when(mockService.performAction()).thenThrow(new RuntimeException(«Error occurred!»));<\/span><\/p>\n

doNothing()<\/b>: Primarily used for void methods, it explicitly states that the method should do nothing when called. By default, void methods on mocks do nothing, but doNothing() can make intent clearer or be used in conjunction with doReturn(), doThrow(), etc., for specific interaction scenarios.<\/span>
\n<\/span>Java<\/span>
\n<\/span>Mockito.doNothing().when(mockLogger).logMessage(Mockito.anyString());<\/span><\/p>\n

doReturn(Object toBeReturned)<\/b>: Used when stubbing a void method, or when spying and you want to stub a method that is called inside the real method. It’s also used for methods that are final or private (though Mockito has limitations with these).<\/span>
\n<\/span>Java<\/span>
\n<\/span>Mockito.doReturn(«Stubbed Result»).when(mockRepository).getData();<\/span><\/p>\n

Mastering these stubbing techniques is crucial for creating robust and isolated unit tests. They allow you to precisely control the behavior of your dependencies, ensuring that the logic of the class under test is thoroughly validated across various scenarios, including both expected and exceptional conditions.<\/span><\/p>\n

Confirming Interactions: Verifying Method Invocations with Mockito<\/b><\/p>\n

One of the most compelling features of Mockito, beyond merely defining mock behavior, is its robust capability to verify method invocations and interactions on mock objects. This verification process is fundamental to ensuring that the code under test not only produces the correct output but also interacts with its dependencies in the precise manner expected. It allows developers to assert that specific methods were indeed called, the correct number of times, and with the exact arguments. This section will delve into the various techniques Mockito provides for verifying these crucial interactions, cementing the reliability of your unit tests.<\/span><\/p>\n

The verify() Method: Asserting Basic Invocation<\/b><\/p>\n

The most fundamental method for interaction verification in Mockito is Mockito.verify(). This method is used to ascertain whether a specific method was invoked on a mock object at least once during the test execution. It provides a simple yet powerful way to confirm that a particular interaction occurred as intended by your code under test.<\/span><\/p>\n

Here is an example demonstrating the use of verify():<\/span><\/p>\n

Java<\/span><\/p>\n

import org.junit.jupiter.api.Test;<\/span><\/p>\n

import org.mockito.Mockito;<\/span><\/p>\n

public class UserServiceTest {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@Test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0public void testCreateUserAccount() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 1. Create a mock object for the UserRepository dependency<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0UserRepository mockUserRepository = Mockito.mock(UserRepository.class);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 2. Create the class under test, injecting the mock<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0UserService userService = new UserService(mockUserRepository);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 3. Act: Invoke the method on the class under test that interacts with the mock<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0User newUser = new User(«alice.smith», «Alice Smith»);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0userService.createUser(newUser);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 4. Verify: Assert that the ‘save’ method was called on the mockUserRepository<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/\u00a0 \u00a0 This checks if the userService correctly delegated the saving operation.<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Mockito.verify(mockUserRepository).save(newUser);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

}<\/span><\/p>\n

In this illustrative scenario, Mockito.verify(mockUserRepository).save(newUser); serves to confirm with absolute certainty that the save() method of the mockUserRepository was invoked at least once during the execution of userService.createUser(), and importantly, that it was invoked with the specific newUser object as its argument. This ensures that the UserService correctly interacts with its persistence layer.<\/span><\/p>\n

Quantifying Invocations: Using verify() with times()<\/b><\/p>\n

Often, it is not sufficient to merely ascertain that a method was called; it is equally important to verify <\/span>how many times<\/span><\/i> it was invoked. The Mockito.times() argument, used in conjunction with verify(), allows you to specify the exact expected number of invocations. This is particularly useful for ensuring that loops or repeated operations within your code under test are functioning as anticipated, without redundant or insufficient calls to dependencies.<\/span><\/p>\n

Consider the following example demonstrating verify() with times():<\/span><\/p>\n

Java<\/span><\/p>\n

import org.junit.jupiter.api.Test;<\/span><\/p>\n

import org.mockito.Mockito;<\/span><\/p>\n

public class DataProcessorTest {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@Test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0public void testProcessMultipleRecords() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 1. Create a mock object for the DataStore dependency<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0DataStore mockDataStore = Mockito.mock(DataStore.class);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 2. Create the class under test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0DataProcessor processor = new DataProcessor(mockDataStore);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 3. Act: Invoke a method that calls mockDataStore.save multiple times<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0processor.processRecords(5); \/\/ Assume this method calls mockDataStore.save() 5 times<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 4. Verify: Assert that the ‘save’ method was called exactly 5 times<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Mockito.verify(mockDataStore, Mockito.times(5)).save(Mockito.anyString());<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

}<\/span><\/p>\n

In this example, Mockito.verify(mockDataStore, Mockito.times(5)).save(Mockito.anyString()); asserts that the save() method on the mockDataStore was invoked precisely five times during the processor.processRecords(5) call, regardless of the specific string argument passed in each call (due to Mockito.anyString()).<\/span><\/p>\n

Other times() related verification modes include:<\/span><\/p>\n

Mockito.never()<\/b>: Verifies that a method was <\/span>never<\/span><\/i> called.<\/span>
\n<\/span>Java<\/span>
\n<\/span>Mockito.verify(mockDependency, Mockito.never()).someMethod();<\/span><\/p>\n

Mockito.atLeast(int minNumberOfInvocations)<\/b>: Verifies that a method was called at least a specified number of times.<\/span>
\n<\/span>Java<\/span>
\n<\/span>Mockito.verify(mockDependency, Mockito.atLeast(2)).someMethod();<\/span><\/p>\n

Mockito.atMost(int maxNumberOfInvocations)<\/b>: Verifies that a method was called at most a specified number of times.<\/span>
\n<\/span>Java<\/span>
\n<\/span>Mockito.verify(mockDependency, Mockito.atMost(3)).someMethod();<\/span><\/p>\n

Mockito.only()<\/b>: Verifies that the given method was the <\/span>only<\/span><\/i> method called on the mock.<\/span>
\n<\/span>Java<\/span>
\n<\/span>Mockito.verify(mockDependency, Mockito.only()).singleCallMethod();<\/span><\/p>\n

Precision in Arguments: Using verify() with Argument Matchers<\/b><\/p>\n

To achieve even greater precision in verification, the verify() method can be combined with Mockito’s powerful argument matchers. These matchers allow you to verify that a method was called not just a certain number of times, but also with arguments that meet specific criteria, rather than requiring an exact object equality. This is crucial when the exact object instance might differ, but its properties or type are what matter.<\/span><\/p>\n

Here’s an example demonstrating verify() with argument matching:<\/span><\/p>\n

Java<\/span><\/p>\n

import org.junit.jupiter.api.Test;<\/span><\/p>\n

import org.mockito.Mockito;<\/span><\/p>\n

import static org.mockito.ArgumentMatchers.eq; \/\/ Import static for cleaner code<\/span><\/p>\n

import static org.mockito.ArgumentMatchers.anyInt;<\/span><\/p>\n

public class ReportingServiceTest {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0@Test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0public void testGenerateMonthlyReport() {<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 1. Create a mock object for the ReportGenerator dependency<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ReportGenerator mockReportGenerator = Mockito.mock(ReportGenerator.class);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 2. Create the class under test<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ReportingService service = new ReportingService(mockReportGenerator);<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 3. Act<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0service.generateReport(«Monthly Sales», 2023, 6); \/\/ Generate report for June 2023<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ 4. Verify: Ensure generateReport was called with specific arguments<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/\u00a0 \u00a0 ‘eq(«Monthly Sales»)’ ensures the first argument is exactly «Monthly Sales»<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/\u00a0 \u00a0 ‘anyInt()’ allows any integer for the year and month<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Mockito.verify(mockReportGenerator).generateReport(eq(«Monthly Sales»), eq(2023), eq(6));<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

}<\/span><\/p>\n

In this example, Mockito.verify(mockReportGenerator).generateReport(eq(«Monthly Sales»), eq(2023), eq(6)); precisely verifies that the generateReport() method was invoked on mockReportGenerator with the exact string «Monthly Sales» and the integer values 2023 and 6. If any of these arguments differed, the verification would fail.<\/span><\/p>\n

Common argument matchers include:<\/span><\/p>\n