Why mocking isolates units under test in JUnit - Automation Benefits in Action

Verify that mocking dependencies isolates the unit under test

Preconditions (2)

Step 1: Create a mock of the Service class

Step 2: Inject the mock Service into the Calculator instance

Step 3: Call the Calculator's method that uses the Service

Step 4: Verify that the Calculator method returns the expected result based on the mock behavior

Step 5: Verify that the Service mock was called as expected

✅ Expected Result: The Calculator method returns the expected result without calling the real Service implementation, proving the unit is isolated

Automation Requirements - JUnit 5 with Mockito

Assertions Needed:

Assert that the Calculator method returns the expected value

Verify that the mock Service method was called exactly once

Best Practices:

Use @Mock and @InjectMocks annotations for cleaner setup

Use Mockito's when-thenReturn to define mock behavior

Use verify to check interactions with mocks

Keep tests focused on one unit only

Automated Solution

JUnit

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;

// External service interface
interface Service {
    int getValue();
}

// Class under test
class Calculator {
    private final Service service;

    public Calculator(Service service) {
        this.service = service;
    }

    public int calculate() {
        // Uses service to get a value and adds 10
        return service.getValue() + 10;
    }
}

@ExtendWith(MockitoExtension.class)
public class CalculatorTest {

    @Mock
    Service serviceMock;

    @InjectMocks
    Calculator calculator;

    @Test
    void testCalculateWithMockedService() {
        // Arrange: define mock behavior
        when(serviceMock.getValue()).thenReturn(5);

        // Act: call method under test
        int result = calculator.calculate();

        // Assert: verify result is as expected
        assertEquals(15, result, "Calculator should add 10 to mocked service value");

        // Verify: service method was called once
        verify(serviceMock, times(1)).getValue();
    }
}

This test uses Mockito to create a mock of the Service interface. The Calculator depends on this service.

By mocking Service, we control its behavior to return 5 when getValue() is called.

This isolates the Calculator from the real Service implementation, so the test only verifies Calculator's logic.

The @Mock annotation creates the mock, and @InjectMocks injects it into the Calculator instance.

The test asserts that the result is 15 (5 from mock + 10), and verifies the mock method was called exactly once.

This shows how mocking isolates the unit under test by replacing dependencies with controlled mocks.

Common Mistakes - 4 Pitfalls

Not using @ExtendWith(MockitoExtension.class) causing mocks not to initialize

{'mistake': 'Calling real methods on dependencies instead of mocking', 'why_bad': 'Test depends on external code, breaking isolation and making tests flaky or slow', 'correct_approach': "Use Mockito's when-thenReturn to define mock behavior and avoid calling real implementations"}

Not verifying interactions with mocks

Mixing multiple units in one test

Bonus Challenge

Now add data-driven testing with 3 different mock return values and expected results

Show Hint

Practice

1. Why do we use mocking in JUnit tests?
Mocking helps to:

easy

A. Replace the entire application with a mock

B. Isolate the unit under test by replacing its dependencies with fake objects

C. Automatically generate test data without writing code

D. Make the code run slower to catch timing issues

Solution

1. Step 1: Understand the purpose of mocking

   Mocking replaces real dependencies with fake ones to isolate the code being tested.

2. Step 2: Identify the effect on tests

   This isolation makes tests faster and more reliable by controlling external factors.

3. Final Answer:

   Isolate the unit under test by replacing its dependencies with fake objects -> Option B

4. Quick Check:

   Mocking isolates code = D [OK]

Hint: Mocking isolates by faking dependencies [OK]

Common Mistakes:

• Thinking mocking slows tests down
• Believing mocking generates test data automatically
• Confusing mocking with replacing the whole app

2. Which of the following is the correct way to create a mock object using Mockito in JUnit?

easy

A. MyClass mock = new Mock(MyClass);

B. MyClass mock = new MyClass();

C. MyClass mock = mockito.create(MyClass);

D. MyClass mock = Mockito.mock(MyClass.class);

Solution

1. Step 1: Recall Mockito syntax for mocking

   Mockito uses the static method mock() with the class type as argument.

2. Step 2: Check each option

   Only MyClass mock = Mockito.mock(MyClass.class); uses the correct syntax: Mockito.mock(MyClass.class);

3. Final Answer:

   MyClass mock = Mockito.mock(MyClass.class); -> Option D

4. Quick Check:

   Mockito.mock(Class) syntax = A [OK]

Hint: Use Mockito.mock(Class.class) to create mocks [OK]

Common Mistakes:

• Using new keyword instead of Mockito.mock
• Wrong method names like create()
• Incorrect class references without .class

3. Given the following JUnit test code using Mockito:

class ServiceTest {
  @Mock
  Repository repo;

  @InjectMocks
  Service service;

  @Test
  void testGetData() {
    when(repo.getData()).thenReturn("mocked data");
    String result = service.getData();
    assertEquals("mocked data", result);
  }
}

What is the main reason this test passes even if the real Repository is not connected to a database?

medium

A. Because repo is a mock that returns controlled data

B. Because the real Repository is used and connected

C. Because service.getData() ignores the repository

D. Because the test does not check any output

Solution

1. Step 1: Understand the role of @Mock and when()

   The repo is mocked to return "mocked data" when getData() is called.

2. Step 2: Analyze test behavior

   The test passes because the mock returns the expected string, independent of any real database connection.

3. Final Answer:

   Because repo is a mock that returns controlled data -> Option A

4. Quick Check:

   Mock returns controlled data = C [OK]

Hint: Mocks return set values, ignoring real dependencies [OK]

Common Mistakes:

• Assuming real database is used
• Thinking service ignores repository
• Believing test lacks assertions

4. Identify the error in this JUnit test using Mockito:

@Test
void testCalculate() {
  Calculator calc = Mockito.mock(Calculator.class);
  when(calc.add(2, 3)).thenReturn(5);
  int result = calc.add(2, 3);
  assertEquals(6, result);
}

medium

A. The expected value in assertEquals is incorrect

B. The mock is not created properly

C. The when() method is used incorrectly

D. The test method lacks @Mock annotation

Solution

1. Step 1: Review mock setup and behavior

   The mock is set to return 5 when add(2, 3) is called.

2. Step 2: Check assertion correctness

   The assertion expects 6, but the mock returns 5, causing failure.

3. Final Answer:

   The expected value in assertEquals is incorrect -> Option A

4. Quick Check:

   Assert expected matches mock return = B [OK]

Hint: Assert expected value must match mock return [OK]

Common Mistakes:

• Expecting wrong values in assertions
• Confusing mock creation syntax
• Missing @Mock annotation on mock fields

5. In a complex system, why is mocking dependencies important to isolate the unit under test?
Consider a service that calls a database and a web API. Which benefit does mocking these dependencies provide?

hard

A. It automatically fixes bugs in the database and API

B. It makes the service code run slower to simulate real conditions

C. It allows testing the service logic without relying on database or API availability

D. It replaces the need for writing unit tests

Solution

1. Step 1: Understand dependency isolation

   Mocking replaces real dependencies like database and API with controlled fake versions.

2. Step 2: Identify benefits for testing

   This isolation allows testing service logic reliably without depending on external systems' availability or state.

3. Final Answer:

   It allows testing the service logic without relying on database or API availability -> Option C

4. Quick Check:

   Mocking isolates external dependencies = A [OK]

Hint: Mock dependencies to test logic independently [OK]

Common Mistakes:

• Thinking mocking slows code
• Believing mocking fixes bugs automatically
• Confusing mocking with skipping tests