Bird
Raised Fist0
JUnittesting~15 mins

Mocking static methods (Mockito 3.4+) in JUnit - Build an Automation Script

Choose your learning style10 modes available
Verify behavior of a method that calls a static utility method
Preconditions (2)
Step 1: Mock the static method Calculator.add to return a fixed value 10 regardless of input
Step 2: Call MathService.calculateSum with inputs 3 and 7
Step 3: Verify that the returned value from calculateSum is 10
Step 4: Verify that the static method Calculator.add was called exactly once with arguments 3 and 7
✅ Expected Result: The test passes confirming that the static method was mocked correctly and MathService.calculateSum returns the mocked value
Automation Requirements - JUnit 5 with Mockito 3.4+
Assertions Needed:
Assert that MathService.calculateSum returns the mocked value 10
Verify that Calculator.add static method was called once with correct arguments
Best Practices:
Use try-with-resources to open and close the static mock context
Use Mockito's mockStatic method to mock static methods
Use explicit verification of static method calls
Keep test isolated and independent
Automated Solution
JUnit
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.Test;
import org.mockito.MockedStatic;

class Calculator {
    public static int add(int a, int b) {
        return a + b;
    }
}

class MathService {
    public int calculateSum(int x, int y) {
        return Calculator.add(x, y);
    }
}

public class MathServiceTest {

    @Test
    void testCalculateSumWithMockedStatic() {
        try (MockedStatic<Calculator> mockedStatic = mockStatic(Calculator.class)) {
            // Arrange: mock static method to always return 10
            mockedStatic.when(() -> Calculator.add(anyInt(), anyInt())).thenReturn(10);

            MathService service = new MathService();

            // Act
            int result = service.calculateSum(3, 7);

            // Assert
            assertEquals(10, result, "The mocked static method should return 10");

            // Verify static method was called once with arguments 3 and 7
            mockedStatic.verify(() -> Calculator.add(3, 7), times(1));
        }
    }
}

This test mocks the static method Calculator.add using Mockito's mockStatic feature introduced in version 3.4+. The try-with-resources block ensures the static mock is closed after the test to avoid side effects.

Inside the block, we set the static method to always return 10 regardless of input. Then we call MathService.calculateSum(3, 7), which internally calls the mocked static method.

We assert the returned value is 10, confirming the mock worked. Finally, we verify that the static method was called exactly once with the expected arguments (3 and 7). This ensures the method interaction is correct.

This approach keeps the test isolated, clean, and uses best practices for mocking static methods with Mockito 3.4+ and JUnit 5.

Common Mistakes - 4 Pitfalls
Not using try-with-resources to close the static mock
Using Mockito.mock() instead of Mockito.mockStatic() for static methods
{'mistake': 'Not verifying the static method call with correct arguments', 'why_bad': "Without verification, you don't confirm that the static method was called as expected, reducing test reliability.", 'correct_approach': 'Use mockedStatic.verify() with exact arguments to ensure correct method invocation.'}
Mocking static methods globally without scoping
Bonus Challenge

Now add data-driven testing with 3 different input pairs for calculateSum and verify the mocked static method returns 10 each time

Show Hint

Practice

(1/5)
1. What is the main purpose of mocking static methods using Mockito 3.4+ in JUnit tests?
easy
A. To control and simulate the behavior of static methods during testing
B. To improve the performance of static methods in production
C. To replace instance methods with static methods
D. To automatically generate test data for static methods

Solution

  1. Step 1: Understand mocking purpose

    Mocking allows us to simulate or control method behavior during tests to isolate code.
  2. Step 2: Apply to static methods

    Mockito 3.4+ supports mocking static methods to control their output in tests.
  3. Final Answer:

    To control and simulate the behavior of static methods during testing -> Option A
  4. Quick Check:

    Mocking static methods = control behavior [OK]
Hint: Mocking controls method behavior in tests, not production code [OK]
Common Mistakes:
  • Thinking mocking improves production performance
  • Confusing static with instance methods
  • Assuming mocking generates test data automatically
2. Which of the following is the correct syntax to mock a static method Utility.calculate() using Mockito 3.4+ in a JUnit test?
easy
A. try (MockedStatic<Utility> mocked = Mockito.mockStatic(Utility.class)) { mocked.when(Utility::calculate).thenReturn(10); }
B. MockedStatic<Utility> mocked = Mockito.mockStatic(Utility.class); mocked.when(() -> Utility.calculate()).thenReturn(10);
C. Mockito.mockStatic(Utility.calculate()).thenReturn(10);
D. try (MockedStatic mocked = Mockito.mockStatic(Utility.calculate())) { mocked.when(() -> Utility.calculate()).thenReturn(10); }

Solution

  1. Step 1: Use try-with-resources for static mocking

    Mockito.mockStatic requires try-with-resources to auto-close the mock.
  2. Step 2: Use method reference in when()

    Correct syntax uses mocked.when(Utility::calculate) to mock static method.
  3. Final Answer:

    try (MockedStatic<Utility> mocked = Mockito.mockStatic(Utility.class)) { mocked.when(Utility::calculate).thenReturn(10); } -> Option A
  4. Quick Check:

    try-with-resources + method ref = correct syntax [OK]
Hint: Use try-with-resources and method reference for static mocks [OK]
Common Mistakes:
  • Omitting try-with-resources block
  • Calling mockStatic on method instead of class
  • Using wrong lambda syntax in when()
3. Given the following code snippet, what will be the output printed?
try (MockedStatic<Math> mathMock = Mockito.mockStatic(Math.class)) {
    mathMock.when(() -> Math.max(5, 10)).thenReturn(100);
    System.out.println(Math.max(5, 10));
}
System.out.println(Math.max(5, 10));
medium
A. 10 10
B. 100 10
C. 100 100
D. 10 100

Solution

  1. Step 1: Inside try block, static method is mocked

    Math.max(5, 10) returns 100 because of mocked behavior.
  2. Step 2: Outside try block, mock is closed

    Math.max(5, 10) returns normal value 10 after mock is closed.
  3. Final Answer:

    100 10 -> Option B
  4. Quick Check:

    Mock active = 100, mock closed = 10 [OK]
Hint: Mock active inside try block only; outside returns real value [OK]
Common Mistakes:
  • Assuming mock affects calls outside try block
  • Expecting mock to persist after try block
  • Confusing return values of Math.max
4. Identify the error in the following JUnit test code that mocks a static method using Mockito 3.4+:
@Test
void testStaticMock() {
    MockedStatic<Config> configMock = Mockito.mockStatic(Config.class);
    configMock.when(() -> Config.getValue()).thenReturn("mocked");
    assertEquals("mocked", Config.getValue());
}
medium
A. assertEquals arguments are in wrong order
B. Incorrect method reference syntax in when()
C. Missing try-with-resources block to close the static mock
D. Static method cannot be mocked in Mockito 3.4+

Solution

  1. Step 1: Check static mock resource management

    Static mocks must be closed; try-with-resources ensures this automatically.
  2. Step 2: Identify missing try block

    Code creates mock but does not close it, risking side effects.
  3. Final Answer:

    Missing try-with-resources block to close the static mock -> Option C
  4. Quick Check:

    Always use try-with-resources for static mocks [OK]
Hint: Always wrap static mocks in try-with-resources to auto-close [OK]
Common Mistakes:
  • Not closing static mocks causing test interference
  • Using wrong lambda syntax in when()
  • Mixing up assertEquals argument order
5. You want to test a method that calls Logger.log(), a static method, but you want to verify it was called exactly twice during the test. Which Mockito 3.4+ approach correctly achieves this?
hard
A. try (MockedStatic<Logger> loggerMock = Mockito.mockStatic(Logger.class)) { loggerMock.verify(() -> Logger.log(), Mockito.times(2)); }
B. MockedStatic<Logger> loggerMock = Mockito.mockStatic(Logger.class); loggerMock.verify(() -> Logger.log(), Mockito.times(2));
C. Mockito.verifyStatic(Logger.class, Mockito.times(2)); Logger.log();
D. try (MockedStatic<Logger> loggerMock = Mockito.mockStatic(Logger.class)) { Logger.log(); Logger.log(); loggerMock.verify(() -> Logger.log(), Mockito.times(2)); }

Solution

  1. Step 1: Use try-with-resources to mock static Logger

    Static mock must be created and closed properly.
  2. Step 2: Call Logger.log() twice inside try block

    To verify calls, method must be invoked during mock lifetime.
  3. Step 3: Verify Logger.log() called exactly twice

    Use loggerMock.verify with times(2) after calls.
  4. Final Answer:

    try (MockedStatic<Logger> loggerMock = Mockito.mockStatic(Logger.class)) { Logger.log(); Logger.log(); loggerMock.verify(() -> Logger.log(), Mockito.times(2)); } -> Option D
  5. Quick Check:

    Call methods inside try, then verify calls [OK]
Hint: Call static method inside try block before verifying calls [OK]
Common Mistakes:
  • Verifying calls without invoking method
  • Not using try-with-resources for static mocks
  • Using Mockito.verifyStatic without proper context
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard