0

I am using Mockito and PowerMock with JUnit. The coverage tool used is ECLEmma. The code that is unit tested with PowerMock, the coverage is shown in red (uncovered).

Here are my the POM mock dependencies

<powermock.version>1.6.5</powermock.version>

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-module-javaagent</artifactId>
    <version>2.0.0</version>
</dependency>

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-module-junit4-rule</artifactId>
    <version>2.0.0</version>
    <scope>test</scope>
</dependency>

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-module-junit4</artifactId>
    <version>${powermock.version}</version>
    <scope>test</scope>
</dependency>

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-api-mockito</artifactId>
    <version>${powermock.version}</version>
    <scope>test</scope>
</dependency>

When I'm using

@RunWith(PowerMockRunner.class)

The Junit runs successfully. but the coverage is all RED. Nothing gets covered

The Mocking references used in the Junit are -

whenNew().withArguments.thenReturn();
ClassName someName = mock(ClassName.class);
WhiteBox.setInternal(classObject, String, classObject2);
Mockito.when().thenReturn();

I tried following this post PowerMock ECLEmma coverage issue and http://www.notonlyanecmplace.com/make-eclemma-test-coverage-work-with-powermock/

But when I add -

@Rule
    public PowerMockRule rule = new PowerMockRule();
    static {
      PowerMockAgent.initializeIfNeeded();
    }

I see the error

    java.lang.NoClassDefFoundError: org/powermock/classloading/ClassloaderExecutor
        at org.powermock.modules.junit4.rule.PowerMockRule.apply(PowerMockRule.java:44)
        at org.junit.runners.BlockJUnit4ClassRunner.withMethodRules(BlockJUnit4ClassRunner.java:365)
        at org.junit.runners.BlockJUnit4ClassRunner.withRules(BlockJUnit4ClassRunner.java:355)
        at 
    Caused by: java.lang.ClassNotFoundException: org.powermock.classloading.ClassloaderExecutor
        at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        ... 18 more

Any suggestions on how this can be resolved?

I have this situation -

 SomeClassName mockedObjectOfSomeClassName = mock(SomeClassName.class);

  whenNew(SomeClassName.class)
   .withArguments("localhost", 8080)
   .thenReturn(mockedObjectOfSomeClassName);

In order to solve the original issue, can some help me first convert this above statement into

doReturn().when(); 

format? I was told if we do that, that should fix the issue.

  • 1
    Do you really rely on `Powermock`? The usual hint for such problems would be to honestly review the own source code, if it can be refactored so that the use of Powermock is no longer necessary. Is this possible for you or do we really have to dig further into the current issue? – mle Mar 16 '19 at 17:35
  • I will have to use Powermock for my case. –  Mar 17 '19 at 04:21
  • I can not get rid of the PowerMock. Any suggestions on what else can I try? –  Mar 18 '19 at 17:32
  • 1
    Well to be honest, not really. Exactly these are the problems of linking two byte-code manipulating frameworks together. For me it was no longer worth the hazzle. – mle Mar 18 '19 at 18:11
  • 1
    May be others could help, but just out of curiosity: what makes it so hard for you to refactor your code to make the need for Powermock obsolete? – mle Mar 18 '19 at 18:12
  • 1
    Honest answer: I dont trust that 4 year old article about powermock and eclemma. To my knowledge, that combination was broken and is broken since ever, and even if you manage to somehow work around it and get it to work ... dont expect that solution to be *robust*. One version upgrade here, or a change there, and things might fall apart again. Our team stopped using PowerMock(ito) years ago, and we simply write better code now, that can (easily) be tested using Mockito. Guess what: we have coverage, we have better code, we dont have bizarre test fails around static code and static mocking... – GhostCat Mar 19 '19 at 18:59

0 Answers0