List of Classes and Methods of org.mockitousage.constructor package of Mockito Framework

OK, this is a bad thing to be doing. Don't mock a list; instead, mock the individual objects inside the list. See Mockito: mocking an arraylist that will be looped in a for loop for how to do this.

Also, why are you using PowerMock? You don't seem to be doing anything that requires PowerMock.

But the real cause of your problem is that you are using when on two different objects, before you complete the stubbing. When you call when, and provide the method call that you are trying to stub, then the very next thing you do in either Mockito OR PowerMock is to specify what happens when that method is called - that is, to do the thenReturn part. Each call to when must be followed by one and only one call to thenReturn, before you do any more calls to when. You made two calls to when without calling thenReturn - that's your error.

There is many correct answers here, but I would like to add my version too. This is based on Assertj.

import static org.assertj.core.api.Assertions.assertThat;

public class TestClass {

    public void test() {
        // do the actual test
        assertThat(actualObject)
            .isEqualToComparingFieldByFieldRecursively(expectedObject);
    }
}

UPDATE: In assertj v3.13.2 this method is deprecated as pointed out by Woodz in comment. Current recommendation is

public class TestClass {

    public void test() {
        // do the actual test
        assertThat(actualObject)
            .usingRecursiveComparison()
            .isEqualTo(expectedObject);
    }

}

Actually org.mockito.Matchers.eq uses org.mockito.internal.matchers.Equality.areEqual(Object o1, Object o2) method to check equality of given matcher to actual value passed to the method. What is interesting, the implementation of this method was stolen from hamcrest as is stated in comment:

//stolen from hamcrest because I didn't want to have more dependency than Matcher class 
//...
public static boolean areEqual(Object o1, Object o2) {
    if (o1 == o2 ) {
        return true;
} else if (o1 == null || o2 == null) {
        return o1 == null && o2 == null;
    } else if (isArray(o1)) {
        return isArray(o2) && areArraysEqual(o1, o2);
    } else {
        return o1.equals(o2);
    }
}

Place a breakpoint at the very beginning of this method to see what is happening in your own code. Since you pass ArrayList to the argument of eq() you may need to dig deeper into areArraysEqual and areArrayLengthsEqual methods.

The thenReturn method will always return what is passed to it. The code new Servicemock() is being executed prior to the call to thenReturn. The created ServiceMock is then being passed to thenReturn. Therefore thenReturn has a absolute instance of ServiceMock not a creation mechanism.

If you need to provide an new instance, use thenAnswer

when(mockedMergeContext.createNewEntityOfType(IService.class))
  .thenAnswer(new Answer<IService>() {
     public IService answer(InvocationOnMock invocation) {
        return new ServiceMock();
     }
   });

Mockito has an isNull matcher, where you can pass in the name of the class. So if you need to use it with other matchers, the correct thing to do is

verify(client).method(eq("String"),isNull(Class<?>.class));

This is now deprecated, see the answer below for the new method - https://stackoverflow.com/a/41250852/1348

You could use a custom answer to do this

MyInterface myMock = mock(MyInterface.class);
Sky sky = buildRandomSkyColor();

when(myMock.methodWithNoArguments()).thenAnswer(new Answer<String>(){
    String answer(InvocationOnMock invocation) {
        if(sky.isBlue())
            return "blue";
        else
            return "gray";
    }
}

From the link you posted;

Default answer of every Mockito mock.

• Returns appropriate primitive for primitive-returning methods
• Returns consistent values for primitive wrapper classes (e.g. int-returning method retuns 0 and Integer-returning method returns 0, too)
• Returns empty collection for collection-returning methods (works for most commonly used collection types)
• Returns description of mock for toString() method
• Returns null for everything else

From the FAQ:

What values do mocks return by default?

In order to be transparent and unobtrusive all Mockito mocks by default return 'nice' values. For example: zeros, falseys, empty collections or nulls.

It was probably done to stay consistent with any other methods which return null for any other non-collection, non-primitive Wrapper objects.

You can always implement your own Answer to pass to mock which returns empty strings for String returning methods.

This is a long time ago question, but here is how i did it, using Mockito spy, create a method which call the parent method in the child class:

public class Child extends Parent {
    /**
     * Shouldn't invoke protected Parent.print() of parent class.
     */
    @Override
    protected String print() {
        // some additional behavior
    return callParent();
    }

    protected callParent()
    {
      super.print();
    }

}

And in the test :

@Test
public void sould_mock_invocation_of_protected_method_of_parent_class() throws Exception {

    // Given
    Child child = Mockito.spy(new Child());
    Mockito.doReturn(null)
           .when(child)
           .callParent();
    // When
    String retrieved = child.print();

    // Then
    Mockito.verify(child, times(1)).callParent(); // verification of child method
    Assert.assertEquals(retrieved, "abc");
}

Note: this test only check we call the parent method in the child class

The primary uses for DI as a technique are :

It leads to a code that is easier to test ( using Mocking ). This means that in order to use mocking frameworks ( Mockito etc ) , you should be using more of DI. If you dont use DI and write code that instantiates objects directly - then practically you cannot use Mockito to mock your dependencies.

Lets say you write code to play an Orchestra. Your main class depends upon so many other classes ( that other people wrote perhaps ).

Lets say you wrote this :

public class Orchestra {
  private Drums drum;
  private Violin violin;
  private Guitar guitar;

public Orchestra() {
    drum = new Drum();
    violin = new Violin();
    guitar = new Guitar();
}

public Music play(){
    // use above in some way to run your orchestra
    // start with violin 
    // add some guitar and then bring in the drums too
}

}

Now you want to ensure that your logic in play works accurately. When you run your class you see the music is not what you are expecting. ( maybe the drummming is starting right at the start ). You want to test the logic of your code play. How would you do that here ? You have no control over your dependencies. You dont know if there was an issue with code of Drum or your own logic in play().

You would want to mock out Drum here. But you cannot do that easily. Because your code does not use DI. Its instantiating the Drum directly inside.

Now lets use DI and see how it helps.

public class Orchestra {
    private Drums drum;
    private Violin violin;
    private Guitar guitar;

    public Orchestra(Drums d,Violin v, Guitar g ) {
        drum = d;
        violin = v;
        guitar = g;
    }

    public Music play(){
        // use above in some way to run your orchestra
    }

}

With this code , it becomes easy to mock out Drum in your test.

class TestOrchestra {

    public void testPlay(){
        Drum mockDrum = mock(Drum.class);
        Violin mockViolin = mock(Violin.class);
        Guitar mockGuitar = mock(Guitar.class);
        // add mock behaviour to above , here you control precisely what these dependencies will do inside your code

        Orchestra orch = new Orchestra(mockDrum, mockViolin,mockGuitar);
        // now play and test your logic

    }

}

The second advantage of using DI is that it helps vary implementations of bigger parts of your program without needing to go through your entire code.

Again - with reference to above , lets say you have been playing your orchestra using a particular type of guitar ( which is instantiated internally by your code).

Now you want to change to an brand new electric guitar.Without DI , you would have to open up your Orchestra class , check where you create the Guitar and change that line of code. You would have to ensure that other parts of your code are not changed inadvertently and test entire Orchestra to make sure things work correctly.

With DI , you could avoid all this. You just inject the new Guitar object into your constructor. Thats it. Because you have tested the new Guitar object on its own ( and it fulfills the contract of the interface Guitar - you can be rest assured that your Orchestra code is not broken by injecting this new Guitar. Thats quite a better improving your orchestra.