Closed GoogleCodeExporter closed 8 years ago
Original comment by tensb...@gmail.com
on 29 Jan 2013 at 10:37
Attachments:
Mmmh looks interesting, could you reproduce it with your own classes ?
Just as a reminder, it's usually a bad idea to mock types you don't own.
Original comment by brice.du...@gmail.com
on 29 Jan 2013 at 10:46
Thanks for the fast feedback. I experimented some more and now think that this
is not a Mockito bug but one of the normal limitations of cglib.
The implementation of java.awt.Container.addImpl has changed between Java 6 and
7. The package-private methods which fail with Java 7 did not exists in Java 6.
So this explains why the test case works with Java 6.
The other question is why the package-private methods are not stubbed by cglib.
I guess this is because Container is loaded from the bootstrap class loader and
cglib thus can't override the package-private classes.
I think you can close this issue as "not a bug" and also change the summary to
"Container.add(mock(Container.class)) fails in Java 7". My experiments
convinced me that mocking package-protected methods generally work the same in
both Java 6 and 7.
Original comment by tensb...@gmail.com
on 29 Jan 2013 at 3:07
Glad you came around it.
> The implementation of java.awt.Container.addImpl has changed between Java 6
and 7.
That's one of the reason why mocking type we don't own is a bad idea ! Instead
using integration tests is probably more relevant. You should read the Growing
Object Oriented Software book, it can be enlightening for in some way. The
authors are at the origin of many testing framework Hamcrest, jMock,
windowlicker (for swing, ...) and influenced many others.
> The other question is why the package-private methods are not stubbed by
cglib. I guess this is because Container is loaded from the bootstrap class
loader and cglib thus can't override the package-private classes.
Yes I believe you are right, I run a few tests and there is a '$' before the
package of system classes, which means package-private methods of these system
class are not visible in the different package of the proxy. Actually package
protected methods are even enforced by the compiler or the JVM itself.
I think the the reason behind this '$' is related to the security of the JVM
itself, i.e. we (coders, or proxies) don't have the permission to define
classes in those packages (even in different jars), so CGLIB chose to prefix
the generated classname by this '$'.
Anyway thank you for reporting, it's actually a very valuable report, which
helped me re/discover a few thing on security, permission, CGLIB, package
methods. Also it shows another example why mocking types not owned can blow at
you in expected ways.
Cheers,
Brice
Original comment by brice.du...@gmail.com
on 29 Jan 2013 at 3:59
Thank your for your feedback. The book looks interesting, I'll have a look at
it.
Cheers
Michael
Original comment by tensb...@gmail.com
on 30 Jan 2013 at 7:40
:)
Also a small erratum :
Also it shows another example why mocking types not owned can blow at you in
UNexpected ways.
Original comment by brice.du...@gmail.com
on 30 Jan 2013 at 9:46
Original issue reported on code.google.com by
tensb...@gmail.com
on 29 Jan 2013 at 10:34