multi-threaded unit tests with Powermockito

1,466 views
Skip to first unread message

ratz

unread,
Dec 30, 2011, 9:36:26 PM12/30/11
to PowerMock
Hi,

I have been trying Powermockito and it was working great. I have some
legacy static methods of a class that I need to mock. My unit tests
were working fine for the simple cases. When I try to write multi-
threaded unit tests, I am facing all kinds of weird problems.

Scenario 1:
I have a class A that calls static methods of another class B. So I
mocked class B containing these static methods. Then I tried to unit
test class A via a single thread, and it worked perfectly.

Scenario 2:
I now have a thread that keeps changing the behavior of the mocked
static methods of class B. Sometimes I make the mocked static methods
to return a valid value, and sometimes I make them throw exceptions.
At the same time, there are multiple threads trying to call the static
methods. I basically want to test how class A fares under
concurrency, when the mocked class B behaves differently.

I am seeing weird issues. with scenario 2. They seem to be related to
threading, since they are happening at different times during
execution. The issue is that when one thread is telling Powermockito
to redefine the behavior of a mocked static method, other threads are
calling the mocked static method at the same time. Is Powermockito
capable of handling such scenarios?

Thanks,
Ratul.

Brice Dutheil

unread,
Jan 1, 2012, 7:39:08 AM1/1/12
to powe...@googlegroups.com
Hi,

I'm not a PowerMock expert, though on Mockito, multithreaded stubbing (on the same mock of course) is not supported and will never be, the way the syntax works makes it impossible. And I'm pretty sure Johan did it differently.

However once stubbed mocks should handle concurrency correctly. So instead of changing the stubs dynamically, you should instead write your own Answer that will behave as it pleases you. (See my answer to your other question).



Hope that helps.

-- 
Brice



--
You received this message because you are subscribed to the Google Groups "PowerMock" group.
To post to this group, send email to powe...@googlegroups.com.
To unsubscribe from this group, send email to powermock+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/powermock?hl=en.


Ratul Mukhopadhyay

unread,
Jan 2, 2012, 2:00:56 PM1/2/12
to powe...@googlegroups.com
Thanks, Brice! I was able to move forward with your reply to my other mail. I have abandoned this approach as you suggested. Just out of curiosity, wat is thr abt the mockito syntax tht will prevent multithreaded stubbing to work? 
--
Regards,
Ratul.

http://ratulmukh.blogspot.com/

Brice Dutheil

unread,
Jan 2, 2012, 2:57:35 PM1/2/12
to powe...@googlegroups.com
Hi,

Erratum in my previous post : "And I'm pretty sure Johan *didn't do it* differently."


Without going into details let's look at this code written using with Mockito :

given(mock.doSomethingWith(eq("A"), longThat(...)).thenReturn("C");

Which is roughly equivalent to :
 (***** NEVER use a reference to OngoingStubbing in real test code, it might lead to wrong test code *****)

String aString = eq("A");
Long aLong = longThat(...);
String variableThatGiveReturnType = mock.doSomethingWith(aString, aLong);
BDDOngoingStubbing<String> ongoingStubbing = given(variableThatGiveReturnType);
ongoingStubbing.thenReturn("C");

The stubbing is clearly not finished until the last call thenReturn is completed, right.

Don't you see the missing link between all those line to actually achieve the stubbing in a fluent way ? ;)

Dependening on how you do that, if you don't synchronize this block you won't be able to achieve any correct stubbing, otherwise concurrent access anywhere in this block will garble things in the mock internals.

And if you add the fact that the mock might be already used, with it's own concurrent code to use the answers, you end up in with completely messed up internal states.



Anyway, always stub before using mocks concurrently.


Cheers,

-- 
Brice

Ratul Mukhopadhyay

unread,
Jan 2, 2012, 6:08:42 PM1/2/12
to powe...@googlegroups.com
Ok, thanks for the explanation! :) That makes sense.
Reply all
Reply to author
Forward
0 new messages