After moving from 1.6.2 to 1.6.6, a "whenNew" call results in the new call returning null, instead of the prepared object

245 views
Skip to first unread message

David Karr

unread,
Jan 22, 2017, 9:02:40 PM1/22/17
to PowerMock
I'm working with a large maven multiproject build, trying to integrate jacoco.  Most of the tests use PowerMock.  Before I started the JaCoCo work, I was using version 1.6.2 of PowerMock.  The latest version of JaCoCo requires version 1.6.6 of PowerMock, so I upgraded PowerMock.

In the "setup" portion of a test, I have a block like the following:
   
    PowerMockito.whenNew(BlahBlah.class)
               
.withArguments(anyObject())
               
.thenReturn(preparedBlahBlahObject);


The block of code this is trying to manipulate is like this:
return process(ctx,new BlahBlah(pRequest));

I also note that the class that this block is in is referenced in a "@PrepareForTest" annotation at the top of the unit test class.

What I'm finding is that the second parameter to the "process" method is null.  Not the prepared instance, and not an ordinary new instance of the class.

I also verified while stepping through the code that "preparedBlahBlahObject" is NOT null.

David Karr

unread,
Jan 22, 2017, 9:10:01 PM1/22/17
to PowerMock

I don't know if it's even valid to do this, but while stepping through the method with the "whenNew()" call, at the end of the method, after the "whenNew()" call, I tried executing the following in the "Display" vi
new BlahBlah(new RequestType())

 What it returned was a "plain" object, with no PowerMock indicators in the class name.

I even tried changing the "withArguments(anyObject())" to "withAnyArguments()".  Same result.

David Karr

unread,
Jan 23, 2017, 3:33:02 PM1/23/17
to PowerMock
On Sunday, January 22, 2017 at 6:02:40 PM UTC-8, David Karr wrote:

I've managed to get this to work, but I'd like to understand why I had to do what I did.

To be clear, this test was working fine when we were using PowerMock 1.6.2.  Upgrading to 1.6.6 caused it to fail.

I finally decided to try augmenting the "@PrepareForTest" annotation, adding the "BlahBlah" class, in addition to the class where the "new BlahBlah()" is called.  That fixed the problem.  Were there particular changes between 1.6.2 and 1.6.6 that would have caused this change to be required?

David Karr

unread,
Jan 23, 2017, 3:58:49 PM1/23/17
to PowerMock

I realized that there was another change I made to get this to work, a change that I don't consider an acceptable workaround.

The original "whenNew()" block looked like this:
        PowerMockito.whenNew(BlahBlah.class)
               
.withArguments(any(SomeClass.class))
               
.thenReturn(blahBlahInstance);

Even with the addition to the @PrepareForTest annotation, this test would still result in the "new()" call returning null.  The only way I could get this to work was changing it to this:
        PowerMockito.whenNew(CsiUnifiedCreditVerificationAnswersProcessor.class)
               
.withAnyArguments()
               
.thenReturn(csiUnifiedCreditVerificationAnswersProcessor);


I also tried "withArguments(anyObject())", and that still failed.

What might be wrong here?


 

Zagretdinov Arthur

unread,
Jan 24, 2017, 1:49:00 AM1/24/17
to powe...@googlegroups.com
Hi,

Thank you for this investigation. 

In PowerMock 1.6.6 has been implemented "Only mock specific calls to new”

Within this task was added correct handling mockito args matchers like `eq`. It should affect using `any*` matchers, but look likes is affected. 

If it possible, could you create a small example to reproduce the issue and create an issue on GitHub? 



Best regrads,
Arthur Zagretdinov


-- 
You received this message because you are subscribed to the Google Groups "PowerMock" group.
To unsubscribe from this group and stop receiving emails from it, send an email to powermock+...@googlegroups.com.
To post to this group, send email to powe...@googlegroups.com.
Visit this group at https://groups.google.com/group/powermock.
For more options, visit https://groups.google.com/d/optout.

David Karr

unread,
Jan 24, 2017, 10:15:38 AM1/24/17
to PowerMock
On Monday, January 23, 2017 at 10:49:00 PM UTC-8, Артур Загретдинов wrote:
Hi,

Thank you for this investigation. 

In PowerMock 1.6.6 has been implemented "Only mock specific calls to new”

Within this task was added correct handling mockito args matchers like `eq`. It should affect using `any*` matchers, but look likes is affected. 

If it possible, could you create a small example to reproduce the issue and create an issue on GitHub? 



Best regrads,
Arthur Zagretdinov

Sigh.  Can you think of a better workaround for now?  I'll work on an isolated test case.

David Karr

unread,
Jan 24, 2017, 11:55:33 AM1/24/17
to PowerMock
On Monday, January 23, 2017 at 10:49:00 PM UTC-8, Артур Загретдинов wrote:
Hi,

Thank you for this investigation. 

In PowerMock 1.6.6 has been implemented "Only mock specific calls to new”

Within this task was added correct handling mockito args matchers like `eq`. It should affect using `any*` matchers, but look likes is affected. 

If it possible, could you create a small example to reproduce the issue and create an issue on GitHub? 

My initial attempts to build an isolated test case have not succeeded.  I'm simply trying to model similar structures from the real code.  Do you have some suggestions for particular aspects of the structure that I should be trying to replicate in order to repeat this problem?
 

David Karr

unread,
Jan 24, 2017, 1:18:51 PM1/24/17
to PowerMock
On Tuesday, January 24, 2017 at 8:55:33 AM UTC-8, David Karr wrote:
On Monday, January 23, 2017 at 10:49:00 PM UTC-8, Артур Загретдинов wrote:
Hi,

Thank you for this investigation. 

In PowerMock 1.6.6 has been implemented "Only mock specific calls to new”

Within this task was added correct handling mockito args matchers like `eq`. It should affect using `any*` matchers, but look likes is affected. 

If it possible, could you create a small example to reproduce the issue and create an issue on GitHub? 

My initial attempts to build an isolated test case have not succeeded.  I'm simply trying to model similar structures from the real code.  Do you have some suggestions for particular aspects of the structure that I should be trying to replicate in order to repeat this problem?

Note that I tried changing the expression from "any(SomeClass.class)" to "eq(someClassInstance)", and it still results in a null return from new in my real code.  My isolated test case still doesn't fail.
 
Reply all
Reply to author
Forward
0 new messages