make spy working with Anonymous classes about mockito HOT 36 CLOSED

Turns out this happened because the instance I wanted to spy on was created 
with an 
anonymous class. More info here: 
http://java.sun.com/javase/6/docs/api/java/lang/
Class.html#getSimpleName()

Thanks, let me look at it

Unfortunately you won't be able to create a spy of an anonymous class because 
this
class is implicitly final. I fixed it so now there is nicer exception saying why
can't you do it. Fix is in trunk.

I will look further, maybe there is a clean way of getting anonymous classes 
working
with spy()

You can't generate a wrapper class? The anonymous class do have a base or 
interface 
whos contract they adhere to. Though I don't know how you would handle it if 
they 
define their own public methods. Maybe that part can be ignored/thrown at, 
since it 
is probably an unlikely event anyway.

>The anonymous class do have a base or interface whos contract they adhere to.

Yes, I'll try fix it in next version

Will try to fix it after 1.7. I don't seem it's that important because spying on
anonymous classes is not very usual and one can always convert anonymous class 
into
nested.

I officially don't have time for this feature :) 

If anyone is keen on this feature, please submit a patch.

I've long since worked around it, and have not run into the need to spy on, 
well, 
anything really, since. So it's no longer important to me.

One simple workaround would be for Mockito implement the following method:
static <T> T spy(Class<? super T> clazz, T object) 

This would let you specify the interface seperately, so mockito won't have to 
build a
proxy of the actual object, but of the interface instead. The proxy could 
however
still redirect incoming calls to the supplied object.

This should solve the problem with final and anonymous classes.

Does this make sense to anyone?
Would it be hard to implement?

[deleted comment]

Ok, I withdraw my patch, it doesn't work for proxys.
It is easy to fix that, but then some tests break.

It's easy to fix the tests but the question boils down to:
Why does Mockito require that the spiedInstance is of the exactly same type as 
the
declared class? Is there any fundamental limitation that requires this, or can 
that
requirement be removed?

If so, I have a working patch available now.

>Why does Mockito require that the spiedInstance is of the exactly same type as 
the
>declared class?

I guess it was the easiest :)

Given that we allow different mocked type and spied instance what type should be
actually proxied? spiedInstance.getClass() or mockedType?

I think mockedType should be proxied. That should work since 
spiedInstance.getClass()
is guaranteed to support all methods from mocketType.

I will send a new patch as soon as I have working tests for final classes, 
anonymous
classes and proxy classes.

I currently need to disable or weaken a couple of conditions in the code, which 
makes
me nervous, but I hope I won't break too much. :-)

No worries, take your time.

I've tried digging into the code now, but it seems I am in way over my head, so 
I am
giving up :-(
However, I still think the original strategy is a sane one.

My suggested API change is:
public static <T, U extends T> T spy(U object, Class<T> clazz);

Hope someone with more understanding of the Mockito core can implement this 
some day.

I made a proof of concept patch and emailed it to the mailing list, but I might 
as
well put it here as well:

Hi man,

Currently, we try not to introduce new methods to the main Mockito class. Have 
a look
at withSettings(). 

AFAIU the goal of this enhancement is to be able to spy on anonymous classes. 
I'm not
sure why we need to introduce new methods. Can we make it working first with the
original spy() method, e.g. to support:

Foo foo = spy(new Foo() {});

Makes sense?

Ok, I can understand not wanting to introduce entirely new features or rewriting
large parts of the code.

Adding a new method should be fully backwards compatible though.

The reason for adding a new method is, in my opinion, that the original 
approach is
wrong.
Spying should not require you to extend a final, anonymous or proxied class, 
which
this basically requires you to do, By supplying the base class or interface 
you're
actually interested in, you avoid that whole mess, without any loss at all for 
most
spying use cases.

For a real time use case, I have a service interface, that performs certain
operations, possibly against a database in the background.
In order to make such implementations transactional, I have made a
TransactionProxy-class, which has a method for wrapping an object in a proxy and
providing the proper transaction-logic:

ServiceImpl si = new ServiceImpl();
Service s = TransactionProxy.wrap(Service.class, si);

It is very hard to spy on such an object in Mockito without introducing this 
new method.

Our current workaround is unfortunately to create the mock manually which is a 
bit
sad, since we're already using a perfectly good mocking framework.

Hey,

I'm open to new features and I can help but I need to understand the purpose :)
Starting from the example you showed what is the use case?

ServiceImpl si = new ServiceImpl();
Service s = TransactionProxy.wrap(Service.class, si);
...

Basically the use case is that we run with real code, but want to verify that 
some
other code calls it the correct amount of time.

ServiceImpl si = new ServiceImpl();
Service s = TransactionProxy.wrap(Service.class, si);
OtherService s2 = new RealOtherService(s);
s2.doSomeOperation();
verify(s, times(2)).update();

That's pretty much exactly our use case that prompted this patch, but with some
changed names and removal of irrelevant code.

ok, cool.

So the use case you show is something Mockito already does. What's so special 
about
the ServiceImpl that requires extra changes?

Sorry, i forgot the actual spy call, here's how it should look:

ServiceImpl si = new ServiceImpl();
Service s = TransactionProxy.wrap(Service.class, si);
Service mySpy = Mockito.spy(s);

OtherService s2 = new RealOtherService(mySpy);
s2.doSomeOperation();
verify(mySpy, times(2)).update();

This is currently not possible in Mockito since spy won't work on a proxied 
object.

Ok I understand now. So the problem is that spy won't work on a proxied object. 
The
spy you're asking for is the behavior of Mockito spies < 1.8.0. Actually, there 
were
many users asking for 'true' partial mocks (meaning to just mere delegators). 
Anyway,
I think the behavior you want can be implemented using current api (correct me 
if I'm
wrong):

        //given
        final IMethods delegate = mock(IMethods.class);
        when(delegate.simpleMethod()).thenReturn("simple");
        when(delegate.otherMethod()).thenReturn("other");

        IMethods mock = mock(IMethods.class, new Answer() {
            public Object answer(InvocationOnMock invocation) throws Throwable {
                return invocation.getMethod().invoke(delegate,
invocation.getArguments());
            }
        });

        when(mock.otherMethod()).thenReturn("overridden other");

        //then
        assertEquals("simple", mock.simpleMethod());
        assertEquals("overridden other", mock.otherMethod());

Yes, that looks like it would work, though with slightly more effort than with 
my 
proposal.

It's an acceptable solution though!

Thanks!

That's true, you have to code some more ;) However you can refactor a bit and 
get:

IMethods mock = mock(IMethods.class, byDefaultDelegateTo(delegate));

Mocking/spying anonymous classes would be extremely useful for Scala, since 
closures in Scala seem to be 
represented by anonymous classes.

FYI, Spying on anonymous classes was implemented in Mockito 1.8.1

Mocking (Mockito.mock(...)) anonymous classes does not make sense :)

"Mocking (Mockito.mock(...)) anonymous classes does not make sense :)"

Quite true. A silly mistake on my part!

With regards to spying on closures in Scala, it appears they're actually final 
classes- and not 
anonymous classes as I had earlier supposed.

For the curious: PowerMock can't quite get around this yet because closures are 
considered inner 
classes, and there seem to be issues with final inner classes.

Oh right, thanks for info!

[deleted comment]

I got into the same issue now when trying to use Mockito with Spring. The issue 
is that Spring creates a proxy/anonymous class in order to apply it's aspects 
(JPA persistence related - wrapping for transactions etc), thus when I get to 
spy on it, it's already an anonymous.
I'll find a workaround, but thought I'd highlight one case when such a feature 
would be useful and which is pretty frequent.

Cheers, Stef.

Hi stefan,

I don't know precisely how your code is configured, but JDK or CGLIB proxies 
are not mockable or spyable, (Mockito will try to create a subclass in bot 
cases). Even spring cannot proxy another proxy directly, instead they need the 
interface.

In the mockito the API of version 1.9.5 we introduced the following ability for 
some corner cases where mocking or spying is difficult if not impossible :

Mockito.mock(SomeMockableType.class, 
AdditionalAnswers.delegatesTo(someInstanceThatIsNotMockableOrSpyable));

HTH
Brice