Why Switch from PowerMock to Mockito‑Only? A Practical Migration Guide

This article discusses the necessity and practical methods for migrating a test environment from using PowerMock to a Mockito‑Only strategy, especially when upgrading to JDK 11.

Why remove PowerMock?

PowerMock only supports up to JDK 9 and has been unmaintained for a long time, leading to compatibility issues with newer JDK versions. Continuing to use an abandoned framework risks inability to use new language features, so the JDK 11 upgrade presents an ideal opportunity to eliminate PowerMock and adopt Mockito‑Only.

Mockito is actively maintained and continuously adapts to newer JDK releases.

Relevant links: https://github.com/powermock/powermock https://github.com/mockito/mockito/releases/tag/v5.0.0

PowerMock also suffers from memory‑leak issues that remain unresolved in its issue tracker.

Issue reference: https://github.com/powermock/powermock/issues/227

How to remove PowerMock dependency

The migration consists of two major parts: removing PowerMock and replacing its mock functionality with Mockito, and handling changes introduced by upgrading Mockito itself.

Mockito‑Only replaces PowerMockito

JUnit Runner

When using Mockito‑Only, the JUnit runner should be set to: @RunWith(MockitoJUnitRunner.class) For Spring‑Test scenarios, Mockito does not provide a direct equivalent to PowerMock’s @PowerMockRunnerDelegate, but the same effect can be achieved by configuring a Mockito JUnit Rule in the test class.

public class ExampleTestClass {
    @Rule public MockitoRule mockito = MockitoJUnit.rule();
    ...
    @Test
    public void test() {
        ...
    }
}

Mocking static methods

Mockito’s latest version also supports static method mocking with the same usage as PowerMock.

Mocking private and final methods

Mockito cannot mock private or final methods; code must be refactored. PowerMock excels in these scenarios, but reliance on it encourages overly complex code.

Mocking private and final fields

Mockito cannot set private or final fields. PowerMock’s Whitebox is unavailable, but third‑party utilities such as Apache Commons FieldUtils can set private fields (final fields still require refactoring).

Reusing mock rules

To simplify and reuse mock configurations, extract them into a reusable rule. PowerMock implements this via PowerMockPolicy:

public class ContextMockPolicy implements PowerMockPolicy {
    @Override
    public void applyClassLoadingPolicy(MockPolicyClassLoadingSettings settings) {
        settings.addFullyQualifiedNamesOfClassesToLoadByMockClassloader(Xxx.class.getName());
    }
    @Override
    public void applyInterceptionPolicy(MockPolicyInterceptionSettings settings) {
        Method getXxx = Whitebox.getMethod(Xxx.class, "getXxx");
        settings.stubMethod(getXxx, Optional.ofNullable(mockXxx()));
        Method getXxxXxx = Whitebox.getMethod(Xxx.class, "getXxxXxx");
        settings.stubMethod(getXxxXxx, Optional.ofNullable(Xxx));
    }
}

With Mockito‑Only the same effect can be achieved using a JUnit ClassRule:

public class ContextMockRule implements TestRule {
    private MockedStatic<Xxx> mockedStatic;
    @Override
    public Statement apply(Statement base, Description description) {
        return new Statement() {
            @Override
            public void evaluate() throws Throwable {
                try {
                    mockXxx();
                    base.evaluate();
                } finally {
                    if (mockedStatic != null) {
                        mockedStatic.close();
                    }
                }
            }
        };
    }
    private void mockXxx() {
        mockedStatic = Mockito.mockStatic(Xxx.class);
        mockedStatic.when(() -> Xxx.getXxx()).thenReturn(Optional.ofNullable(mockXxx()));
        mockedStatic.when(() -> Xxx.getXxxXxx()).thenReturn(Optional.ofNullable(Xxx));
    }
}

public class ExampleTestClass {
    @ClassRule public static ContextMockRule contextMockRule = new ContextMockRule();
    ...
    @Test
    public void test() {
        ...
    }
}

Mockito‑Only multithreaded mock limitations

In multithreaded test scenarios (e.g., ExecutorService or ParallelStream), static method mocking may not work, unlike PowerMock.

For ExecutorService we can mock as follows:

ExecutorService chatExecutor = Mockito.mock(ExecutorService.class);
doAnswer(invocation -> {
    Object[] args = invocation.getArguments();
    Callable callable = (Callable) args[0];
    Object result = callable.call();
    FutureTask futureTask = Mockito.mock(FutureTask.class);
    Mockito.when(futureTask.get(anyLong(), any()))
           .thenReturn(result);
    return futureTask;
}).when(chatExecutor).submit(any(Callable.class));

Mockito version incompatibility changes

After upgrading Mockito, several matcher behaviors changed:

Methods like anyLong(), anyString(), and anyObject() no longer accept null; use any() instead.

ArgumentMatcher implementations now have explicit generic types instead of raw Object.

Invocation argument retrieval APIs have been updated.

Efficiently refactoring large test suites

Manually refactoring thousands of unit tests is impractical. Options include:

AI Agent : Define prompts to automatically rewrite test classes, though response time and quality can be limiting.

Custom refactoring script : Use Python with Tree‑sitter to parse and transform test code, automating repetitive steps such as annotation replacement.

Even with automation, some incompatibilities—like Mockito’s multithreaded mock limits—still require manual handling.

Benefits after adopting Mockito‑Only

Test classes become more focused, with fewer PowerMock‑specific annotations and clearer mock lifecycle management, reducing memory‑leak risks.

Unit test execution time dropped from 9 min 53 s to 3 min 57 s, and memory usage fell from ~5 GB to ~2.5 GB on the author’s machine.

Implementation differences between Mockito and PowerMock

Mockito uses Java dynamic proxies for interfaces and ByteBuddy for concrete classes, intercepting method calls via generated proxies and recording interactions for verification.

PowerMock relies on bytecode manipulation (JavaAssist, CGLib), custom class loaders, and JVM‑level proxying to mock static, private, and constructor behavior, often integrating with Mockito or EasyMock for standard mocking.

Summary

Mockito : lightweight, uses dynamic proxies and bytecode generation, handles non‑static, non‑private methods.

PowerMock : employs advanced bytecode manipulation and custom class loading to mock static, private, and constructor calls; more powerful but complex and less maintained.

The choice depends on the required mocking capabilities and the need for maintainable, performant test suites.