What is Mocking in Unit Testing | Java Fresher
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Mocking is replacing a real dependency with a fake one that you control.
You'd say: It's about isolation. When I test a service, I don't want the test to fail because the database is down or an external API is slow. I mock those dependencies so the test only exercises the service's logic.
For example, if I'm testing an order service that fetches data from a repository, I'd mock the repository to return a specific order. Then I test that the service calculates the total price correctly. The mock gives me control—I can make it return success, failure, empty data, whatever scenario I need.
Without mocking, every test would need a running database, test data setup, and network access. That's slow and brittle. The key thing is mocking draws a boundary.
I'm testing the order service, not the repository or the database driver. If the repository has its own bugs, that's a different test. This keeps tests fast and focused.
One pitfall freshers hit is mocking everything, even simple value objects like a product DTO. You only mock things with side effects—external systems, I-O operations, things outside your control. If it's a plain data class, just create a real instance.
What is Mocking in Unit Testing | Java Fresher
Direct Answer
Mocking replaces a real dependency with a controlled fake that you configure to return specific values. It isolates the class under test from its dependencies—database, external APIs, file system—so you test only the unit's logic, not its dependencies.
Code Example
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;
@ExtendWith(MockitoExtension.class)
class OrderServiceTest {
@Mock
private OrderRepository orderRepository; // fake repository
@InjectMocks
private OrderService orderService; // real service under test
@Test
void shouldCalculateTotalPrice() {
var order = new Order(1L, "Laptop", 1200.0);
when(orderRepository.findById(1L)).thenReturn(Optional.of(order)); // stub return value
var total = orderService.calculateTotalWithTax(1L);
assertEquals(1320.0, total); // 1200 + 10% tax
verify(orderRepository).findById(1L); // assert the repo was called
}
}
Common Mistakes & Pitfalls
- Mocking value objects: Freshers mock DTOs, POJOs, or simple data classes that have no behavior—like mocking a
Productobject with just getters. These should be real instances created withnew Product(...)because they have no side effects. - Mocking the class under test: Some beginners mock the service they're testing, then wonder why their test passes even when the real method is broken. You mock the dependencies, never the subject.
- Thinking mocks make tests easier: Mocking isn't a shortcut—it's a surgical tool to isolate behavior. Over-mocking can make tests harder to understand and maintain because you're testing mock configurations instead of real logic.
Check your understanding
Answer these without looking back at the article.
- What is the difference between a mock, stub, and spy?
- When should you NOT mock a dependency?
- What is Mockito?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.