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.