gesiod / mockito

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

Mockito cannot mock interface with large number of methods (~ 1600 methods) #240

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Given interface BigInterface with more than 1600 methods, the following code 
will throw exception instead of creating a mock object:

<code>
Mockito.mock(BigInterface.class);
</code>

Exception message is also somewhat misleading as it says:

<msg>
org.mockito.exceptions.base.MockitoException: 
Mockito cannot mock this class: interface BigInterfaceTest$BigInterface
Mockito can only mock visible & non-final classes.
If you're not sure why you're getting this error, please report to the mailing 
list.
</msg>

Chained exception suggests that problem is caused by cglib-generated java 
method that exceeded some maximum size.

The real life example of such a big interface is:
javax.media.opengl.GL (over 2000 methods)

full testcase and stack-trace in attachement.

reproduced with:
mockito 1.8.5
Xubuntu 10.10
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)

Original issue reported on code.google.com by Marcin.M...@gmail.com on 10 Jan 2011 at 6:50

Attachments:

GoogleCodeExporter commented 8 years ago
Same error hit me today - I used to mock an interface from a library owned by 
another team in our company. They recently updated this library and the 
interface become too huge for CGLIB to manage.

Any way to tell Mockito exactly what methods to mock, I don't mind if calling 
any other method will throw an exception or something..

Original comment by denis.so...@gmail.com on 17 Jan 2011 at 9:57

GoogleCodeExporter commented 8 years ago
Ouch :/

Any volunteers to fix CGLIB?

Guys, what are you mocking? :) Remember that you should not mock types you 
don't own?

Original comment by szcze...@gmail.com on 22 Jan 2011 at 10:28

GoogleCodeExporter commented 8 years ago
We hit this while mocking a GWT resource bundle interface. Is there any 
workaround?

Original comment by gamewith...@gmail.com on 30 Nov 2012 at 11:48

GoogleCodeExporter commented 8 years ago
Hey,

I don't think so. JVM imposes some limitations on the class to be valid, and 
the size is one of these limitations. (check the JVM specs §4.8.1 Static 
Constraints 
[http://docs.oracle.com/javase/specs/jvms/se5.0/html/ClassFile.doc.html#9279]  
or §4.10 Limitations of the Java Virtual Machine 
[http://docs.oracle.com/javase/specs/jvms/se5.0/html/ClassFile.doc.html#88659]) 
That's what is happening to Marcin and probably you.

I'm even sure this is possible without imposing tricks to the user, and 
creating lighter proxies regardless of the chosen approach would require to 
rewrite a good part of CGLIB. Not sure it will happen anytime soon :(

The only workaround I see is to split the code. I would create a concrete 
implementation that will delegate parts of call to more focused types. Then you 
could mock focused types.

I'm tempted to mark this issue as WontFix, as we can't really do something.

Cheers,
Brice

Original comment by brice.du...@gmail.com on 30 Nov 2012 at 1:38

GoogleCodeExporter commented 8 years ago
I hit this issue with a GWT i18n messages interface.

Original comment by l...@ghue.net on 17 Aug 2015 at 6:56