easyforgood / mockito

Automatically exported from code.google.com/p/mockito
0 stars 0 forks source link

On some classes mock objects call actual implementation #417

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The following code shows the problem:

public class AppTest 
{
  @Test  
  public void testApp() {
    OAuthRequest mockRequest=mock(OAuthRequest.class); 
    when(mockRequest.send()).thenReturn(null); // This should NOT call the real implementation
 }
}

While the expectation is for "when" to use the method interception filter and 
work flawlessly, in real life it calls the implementation and tries to access 
the network.
Note that send() is a public method - nothing special.

This is consistent for any method in class OAuthRequest, so it seems related to 
the class in some way.

Used JUnit4, Mockito 1.9.5, Java 1.6 and 1.7, Windows 7 64bit.

I am attaching a zip with the mini-project (pom & all).

Original issue reported on code.google.com by omri.spe...@gmail.com on 4 Feb 2013 at 1:46

Attachments:

GoogleCodeExporter commented 8 years ago
Hi, this is a known issue and I'm not sure if we can do something about it at 
the moment.

The thing is if the parent class of the type we want to mock is not public, 
then the Mockito mock misbehaves, see issue 212 for more details about the 
issue.

Scribe code declares Request as being package private.

public class OAuthRequest extends Request { ...

class Request {
  public Response send() { ...

Original comment by brice.du...@gmail.com on 4 Feb 2013 at 6:36

GoogleCodeExporter commented 8 years ago
Thank you for your answer. Once I realized this then PowerMockito helped me 
solve the issue.
Keep up the good work!

(P.S. for anyone going down this path:
1- add PowerMockito to your project
2- Use PM runner
3- @PrepareForTest(OAuthRequest.class) // solves the issue
4- @PowerMockIgnore({"javax.crypto.*" }) // custom class loading messes with 
crypto
The rest works as usual.)

Original comment by omri.spe...@gmail.com on 4 Feb 2013 at 9:17

GoogleCodeExporter commented 8 years ago
Thanx, one day maybe we could change that though.

Also note in your approach that PowerMock will load classes in another 
classloader, that may be fine for some but for others it can be a bit 
troublesome if the base code is enormous as the way PowerMock works it can eat 
PermGen, etc.

Still, PowerMorck offers incredible tricks to circumvent some limitations. You 
might want to try JMockit too.

Cheers,
Brice

Original comment by brice.du...@gmail.com on 5 Feb 2013 at 9:37