Take the 2-minute tour ×

I've asked a couple of jUnit and Mockito oriented questions recently and I'm still really struggling to get the hang of it. The tutorials are all for very simple examples, so I'm struggling to scale up my test cases to work for my classes.

I'm currently trying to write some test cases for a method I have in one of my agents in a webapp. The method interacts with a couple of other methods inside the agent to validate some objects. I just want to test this one method right now.

Here's what I have tried to do:

  1. Create a Mockito object of my agent like so:

    MyProcessingAgent mockMyAgent = Mockito.mock(MyProcessingAgent.class);

  2. Setup stubs(hopefully the right term) using Mockito.when like so:


  3. Try executing my method like so:

    List myReturnValue = mockMyAgent.methodThatNeedsTestCase();

I was expecting to things in myReturnValue, but received 0 instead so I tried to debug. When I call the method, it never executes. I have a debug point at the first line in the method that never gets touched.

If I want to execute the code in one method of a class, but force other methods in the class (one's that try to interact with databases in the outside world) to return faked out values. Is this possible with Mockito?

It appears that my current method of approach is not a correct testing style, but I'm not sure how to move forward. Can I mock my class and have one method be executed like normal while other methods are stubbed to return my given values so that I don't have to deal with data access during testing this one method?

share|improve this question
add comment

3 Answers

up vote 6 down vote accepted

You are confusing a Mock with a Spy.

In a mock all methods are stubbed and return "smart return types". This means that calling any method on a mocked class with do nothing unless you specify behaviour.

In a spy the original functionality of the class is still there but you can validate method invocations in a spy and also override method behaviour.

What you want is

MyProcessingAgent mockMyAgent = Mockito.spy(MyProcessingAgent.class);

A quick example:

static class TestClass {

    public String getThing() {
        return "Thing";

    public String getOtherThing() {
        return getThing();

public static void main(String[] args) {
    final TestClass testClass = Mockito.spy(new TestClass());
    Mockito.when(testClass.getThing()).thenReturn("Some Other thing");

Output is:

Some Other thing

NB: You should really to mock the dependencies for the class being tested not the class itself.

share|improve this answer
Please see my statement regarding spies and let me know if you disagree. –  John B Apr 12 '13 at 16:15
@JohnB I think you are correct. I have expanded by answer. I did not realise the OP was calling the method internally. –  Boris the Spider Apr 12 '13 at 16:16
Thanks for the detailed descriptions, it is very helpful. So, what both answers are recommending (to clarify) is that I'm attacking the wrong class with Mock. Instead I should be mocking all the data access objects that my class needs, then use a normal instance of my class for testing? –  Kyle Apr 12 '13 at 16:20
So, I was wrong. At least on my box, a spy will catch internal calls. I set up a scenario where m1() calls m2(). I spy the object and stub m2(). In my test I call m1(). m2() in the object is never reached, the stub in invoked. IMHO this is still bad practice but good to know. –  John B Apr 12 '13 at 16:22
@Kyle Your comment is exactly correct –  John B Apr 12 '13 at 16:22
show 3 more comments

So, the idea of mocking the class under test is anathima to testing practice. You should NOT do this. Because you have done so, your test is entering Mockito's mocking classes not your class under test.

Spying will also not work because this only provides a wrapper / proxy around the spied class. Once execution is inside the class it will not go through the proxy and therefore not hit the spy. UPDATE: although I believe this to be true of Spring proxies it appears to not be true of Mockito spies. I set up a scenario where method m1() calls m2(). I spy the object and stub m2() to doNothing. When I invoke m1() in my test, m2() of the class is not reached. Mockito invokes the stub. So using a spy to accomplish what is being asked is possible. However, I would reiterate that I would consider it bad practice (IMHO).

You should mock all the classes on which the class under test depends. This will allow you to control the behavior of the methods invoked by the method under test in that you control the class that those methods invoke.

If your class creates instances of other classes, consider using factories.

share|improve this answer
+1 for the use of a word like anathema, seems harsh, but I think I get your point. I'm still trying to wrap my head around the testing, I guess I just came at this from the completely wrong angle. –  Kyle Apr 12 '13 at 16:21
probably true of a A-word. The fact that you are even doing unit testing is a good sign. Keep it up. Cheers! –  John B Apr 12 '13 at 16:26
+1 good answer –  andyb Apr 12 '13 at 16:32
add comment

You've nearly got it. The problem is that the Class Under Test (CUT) is not built for unit testing - it has not really been TDD'd.

Think of it like this…

  • I need to test a function of a class - let's call it myFunction
  • That function makes a call to a function on another class/service/database
  • That function also calls another method on the CUT

In the unit test

  • Should create a concrete CUT or @Spy on it
  • You can @Mock all of the other class/service/database (i.e. external dependencies)
  • You could stub the other function called in the CUT but it is not really how unit testing should be done

In order to avoid executing code that you are not strictly testing, you could abstract that code away into something that can be @Mocked.

In this very simple example, a function that creates an object will be difficult to test

public void doSomethingCool(String foo) {
    MyObject obj = new MyObject(foo);

    // can't do much with obj in a unit test unless it is returned

But a function that uses a service to get MyObject is easy to test, as we have abstracted the difficult/impossible to test code into something that makes this method testable.

public void doSomethingCool(String foo) {
    MyObject obj = MyObjectService.getMeAnObject(foo);

as MyObjectService can be mocked and also verified that .getMeAnObject() is called with the foo variable.

share|improve this answer
if myFunction and myFunction2 are part of the CUT, and myFunction calls myFunction2 as stated in your example, wouldn't Spy based partial mocking be the only option? should myFunction2 be moved out of the CUT and "injected" even though it is an integral part of the CUT responsibility? what am i missing? –  Nishith Aug 1 '13 at 17:47
I don't think you are missing anything. Spy based partial mock is the best option, although you could just test both methods together. My example was more about the problem when methods in the CUT create objects that you might want to verify behaviour on or assert values in, and that could be accomplished by refactoring the CUT to use a factory or external service to create those objects which can be mocked and injected. –  andyb Aug 2 '13 at 20:28
thanks ... makes sense ... –  Nishith Aug 23 '13 at 8:15
add comment

Your Answer


