@CheckReturnValue
    public static <T> T spy(T object) {
        return MOCKITO_CORE.mock((Class<T>) object.getClass(), withSettings()
                .spiedInstance(object)
                .defaultAnswer(CALLS_REAL_METHODS));
    }
@ CheckReturnValue public static < T > T spy ( T object ) { return MOCKITO_CORE . mock ( ( Class < T > ) object . getClass ( ) , withSettings ( ) . spiedInstance ( object ) . defaultAnswer ( CALLS_REAL_METHODS ) ) ; }
Creates a spy of the real object. The spy calls <b>real</b> methods unless they are stubbed.
<p>
Real spies should be used <b>carefully and occasionally</b>, for example when dealing with legacy code.
<p>
As usual you are going to read <b>the partial mock warning</b>:
Object oriented programming tackles complexity by dividing the complexity into separate, specific, SRPy objects.
How does partial mock fit into this paradigm? Well, it just doesn't...
Partial mock usually means that the complexity has been moved to a different method on the same object.
In most cases, this is not the way you want to design your application.
<p>
However, there are rare cases when partial mocks come handy:
dealing with code you cannot change easily (3rd party interfaces, interim refactoring of legacy code etc.)
However, I wouldn't use partial mocks for new, test-driven & well-designed code.
<p>
Example:

<pre class="code"><code class="java">
List list = new LinkedList();
List spy = spy(list);

//optionally, you can stub out some methods:
when(spy.size()).thenReturn(100);

//using the spy calls <b>real</b> methods
spy.add("one");
spy.add("two");

//prints "one" - the first element of a list
System.out.println(spy.get(0));

//size() method was stubbed - 100 is printed
System.out.println(spy.size());

//optionally, you can verify
verify(spy).add("one");
verify(spy).add("two");
</code></pre>

<h4>Important gotcha on spying real objects!</h4>
<ol>
<li>Sometimes it's impossible or impractical to use {@link Mockito#when(Object)} for stubbing spies.
Therefore for spies it is recommended to always use <code>doReturn</code>|<code>Answer</code>|<code>Throw()</code>|<code>CallRealMethod</code>
family of methods for stubbing. Example:

<pre class="code"><code class="java">
List list = new LinkedList();
List spy = spy(list);

//Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty)
when(spy.get(0)).thenReturn("foo");

//You have to use doReturn() for stubbing
doReturn("foo").when(spy).get(0);
</code></pre>
</li>

<li>Mockito <b>*does not*</b> delegate calls to the passed real instance, instead it actually creates a copy of it.
So if you keep the real instance and interact with it, don't expect the spied to be aware of those interaction
and their effect on real instance state.
The corollary is that when an <b>*unstubbed*</b> method is called <b>*on the spy*</b> but <b>*not on the real instance*</b>,
you won't see any effects on the real instance.</li>

<li>Watch out for final methods.
Mockito doesn't mock final methods so the bottom line is: when you spy on real objects + you try to stub a final method = trouble.
Also you won't be able to verify those method as well.
</li>
</ol>
<p>
See examples in javadoc for {@link Mockito} class

<p>Note that the spy won't have any annotations of the spied type, because CGLIB won't rewrite them.
It may troublesome for code that rely on the spy to have these annotations.</p>


@param object
to spy on
@return a spy of the real object