Summary

• Adds a new PowerMockRunnerDelegateToRunWith recipe that handles @PowerMockRunnerDelegate during PowerMock-to-Mockito migration
• Wires the recipe into ReplacePowerMockito in powermockito.yml, positioned before PowerMockitoMockStaticToMockito

Problem

The Mockito1to3Migration recipe does not handle the @PowerMockRunnerDelegate annotation (org.powermock.modules.junit4.PowerMockRunnerDelegate). When a test class uses both @RunWith(PowerMockRunner.class) and @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class), the migration removes @RunWith(PowerMockRunner.class) but leaves @PowerMockRunnerDelegate untouched, producing invalid code since the PowerMock dependency is no longer present.

Background research

• @PowerMockRunnerDelegate was introduced in PowerMock 1.6.0 to solve a JUnit 4 limitation: only one @RunWith runner can be specified per test class. When a test needs both PowerMock's bytecode manipulation and another runner (e.g., Spring's SpringJUnit4ClassRunner or JUnit's Parameterized), the pattern is:

@RunWith(PowerMockRunner.class)                          // PowerMock classloading wrapper
@PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)  // Actual test runner

PowerMockRunner handles classloading and @PrepareForTest setup, then delegates actual test execution to the runner specified in @PowerMockRunnerDelegate. The delegate is the runner the test actually depends on.

When removing PowerMock, the correct migration is to promote the delegate to @RunWith, since:

1. PowerMockRunner was only a wrapper for classloader tricks — it serves no purpose without PowerMock
2. The delegate runner provides the test's actual lifecycle (Spring context loading, parameterized execution, etc.)
3. Dropping the delegate without promoting it breaks the test

Sources

• PowerMock Wiki: JUnit Delegating Runner
• PowerMock PR #6: PowerMockRunnerDelegate annotation
• Alibaba Cloud: Mock Framework Evolution — From PowerMockito to Mockito Only