bootstrap PowerMock with #Rule ,but failed - junit

Question

#RunWith(PowerMockRunner.class)
#PrepareForTest({ SessionUtil.class})
public class FundControllerTest {
XXXXXXXXXXXXXXX.......
}
Run Junit as above, it works well.
But when I try to run Junit as below, it failed. Because I need use Eclemma to
coverage my test, so I switch to use #Rule to bootstrap PowerMock, but failed. Please help.
#PrepareForTest({ SessionUtil.class})
public class FundControllerTest {
#Rule
public PowerMockRule rule = new PowerMockRule();
/*
static{
PowerMockAgent.initializeIfNeeded();
}
*/
XXXXXXXXXXXXXXXXXXXXXXXXX..........
}
java.lang.RuntimeException: com.sun.tools.attach.AttachNotSupportedException: Unable to enqueue operation: the target VM does not support attach mechanism
at org.powermock.modules.agent.AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(AgentLoader.java:122)
at org.powermock.modules.agent.AgentLoader.loadAgent(AgentLoader.java:81)
at org.powermock.modules.agent.AgentInitialization.initializeAccordingToJDKVersion(AgentInitialization.java:40)
at org.powermock.modules.agent.PowerMockAgent.initializeIfNeeded(PowerMockAgent.java:91)
at com.hsbc.mf.frtend.twfunds.controller.FundControllerTest.<clinit>(FundControllerTest.java:53)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:199)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:56)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39)
at java.lang.reflect.Constructor.newInstance(Constructor.java:527)
at org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunner.java:217)
at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:266)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to enqueue operation: the target VM does not support attach mechanism
at sun.tools.attach.WindowsVirtualMachine.<init>(WindowsVirtualMachine.java:64)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:56)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39)
at java.lang.reflect.Constructor.newInstance(Constructor.java:527)
at org.powermock.reflect.internal.WhiteboxImpl.createInstance(WhiteboxImpl.java:1455)
at org.powermock.reflect.internal.WhiteboxImpl.invokeConstructor(WhiteboxImpl.java:1303)
at org.powermock.reflect.Whitebox.invokeConstructor(Whitebox.java:497)
at org.powermock.modules.agent.AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(AgentLoader.java:120)
... 28 more

Answer 1

When you find a snake in your bed, does it matter whether it crawled through the open window; or came through the front door?
In other words: in order to allow for mocking static code; PowerMock needs to manipulate the byte code of that production class SessionUtils. And EclEmma also relies on byte code manipulation.
Perhaps, at some future point, the implementations of both frameworks will work together (but the corresponding bug is almost two years old; and there isn't much activity around it; so don't hold your breath on it).
But today, PowerMock and EclEmma do not work together. End of story.
And it doesn't matter to "pull in" PowerMock using its own runner; or using the "rule approach". Because as said: the problem is that you found that snake in your bed; and not "how did it get there".
Now you simply have to decide what is more important to you: to keep your production code as is (and its design, that forces you to mock static calls with PowerMock); or to acquire coverage information.
My personal two cents: that is one of the reasons why my team gave up on PowerMock completely. Instead, we focus on writing code that is testable without mocking static/new calls; and guess what: that works fine. And our production code is better than before.