Mocking static methods (Mockito 3.4+) in JUnit - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Mockito static mock test?

Consider the following JUnit test using Mockito 3.4+ to mock a static method. What will be the printed output when the test runs?

JUnit

import static org.mockito.Mockito.*;
import org.mockito.MockedStatic;
import org.junit.jupiter.api.Test;

class Utility {
    static String greet() {
        return "Hello";
    }
}

public class StaticMockTest {
    @Test
    void testStaticMock() {
        try (MockedStatic<Utility> mocked = mockStatic(Utility.class)) {
            mocked.when(Utility::greet).thenReturn("Hi");
            System.out.println(Utility.greet());
        }
        System.out.println(Utility.greet());
    }
}

A Hello\nHello

B Hi\nHello

C Hi\nHi

D Hello\nHi

💡 Hint

Think about the scope of the static mock and what happens after the try-with-resources block.

Inside the try-with-resources block, the static method greet() is mocked to return "Hi". After the block, the mock is closed, so the original method returns "Hello" again.

❓ assertion

intermediate

Which assertion correctly verifies the static method was called exactly twice?

Given a mocked static method using Mockito 3.4+, which assertion correctly verifies that the static method Utility.greet() was called exactly two times?

JUnit

try (MockedStatic<Utility> mocked = mockStatic(Utility.class)) {
    mocked.when(Utility::greet).thenReturn("Hi");
    Utility.greet();
    Utility.greet();
    // Which assertion below is correct?
}

A verify(Utility.class, times(2)).greet();

B verifyStatic(Utility.class, times(2)); Utility.greet();

C mocked.verify(Utility.greet(), times(2));

D mocked.verify(Utility::greet, times(2));

💡 Hint

Check how to verify calls on MockedStatic instances.

The correct way is to call verify on the MockedStatic instance with a method reference and times(2). Option D is invalid because verify() is not used for static mocks that way. Option D passes a method call instead of a method reference. Option D is deprecated and incomplete.

🔧 Debug

advanced

Why does this Mockito static mock test fail with NullPointerException?

Examine the following test code. Why does it throw a NullPointerException during execution?

JUnit

import static org.mockito.Mockito.*;
import org.mockito.MockedStatic;
import org.junit.jupiter.api.Test;

class Utility {
    static String greet() {
        return "Hello";
    }
}

public class StaticMockTest {
    @Test
    void testStaticMock() {
        MockedStatic<Utility> mocked = mockStatic(Utility.class);
        mocked.when(Utility::greet).thenReturn(null);
        String result = Utility.greet().toUpperCase();
        mocked.close();
    }
}

A Utility.greet() returns null, so calling toUpperCase() causes NullPointerException.

B mockStatic() was not called inside try-with-resources, causing resource leak and failure.

C Mockito cannot mock static methods returning String, causing NullPointerException.

D The mocked.when() syntax is incorrect, causing NullPointerException.

💡 Hint

Check what happens when you call a method on a null object.

The mocked static method is set to return null. Then the test calls toUpperCase() on that null, causing NullPointerException.

❓ framework

advanced

Which Mockito version introduced static method mocking support?

Mockito added support for mocking static methods in which version?

A 4.0.0

B 2.28.0

C 3.4.0

D 3.0.0

💡 Hint

Check Mockito release notes for static mocking feature introduction.

Mockito 3.4.0 was the first version to officially support static method mocking.

🧠 Conceptual

expert

What is a key limitation when mocking static methods with Mockito 3.4+?

Which of the following is a key limitation or consideration when mocking static methods using Mockito 3.4+?

A Static mocks must be used within try-with-resources or closed manually to avoid side effects.

B Static methods can only be mocked if they are public and non-final.

C Mockito requires the static method to be in the same package as the test class.

D Static method mocking disables all other mocks in the test class.

💡 Hint

Think about resource management and test isolation.

Static mocks affect the JVM globally, so they must be closed to avoid affecting other tests. This is why try-with-resources or manual close is required.

Practice

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