How to use shouldNotThrowNPEWhenCloningNulls method of org.mockitousage.stubbing.StubbingWithThrowablesTest class

Here is a good start using Mockito to test your UserDAO. This code uses a good amount of the Mockito features, so you can see how to use them. Let me know if you have questions.

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import javax.sql.DataSource;
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
import static org.junit.Assert.*;
import org.junit.runner.RunWith;
import static org.mockito.Matchers.anyInt;
import static org.mockito.Matchers.anyString;
import org.mockito.Mock;
import static org.mockito.Mockito.doNothing;
import static org.mockito.Mockito.times;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;
import org.mockito.runners.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class TestUserDAO {

    @Mock
    DataSource mockDataSource;
    @Mock
    Connection mockConn;
    @Mock
    PreparedStatement mockPreparedStmnt;
    @Mock
    ResultSet mockResultSet;
    int userId = 100;

    public TestUserDAO() {
    }

    @BeforeClass
    public static void setUpClass() throws Exception {
    }

    @AfterClass
    public static void tearDownClass() {
    }

    @Before
    public void setUp() throws SQLException {
        when(mockDataSource.getConnection()).thenReturn(mockConn);
        when(mockDataSource.getConnection(anyString(), anyString())).thenReturn(mockConn);
        doNothing().when(mockConn).commit();
        when(mockConn.prepareStatement(anyString(), anyInt())).thenReturn(mockPreparedStmnt);
        doNothing().when(mockPreparedStmnt).setString(anyInt(), anyString());
        when(mockPreparedStmnt.execute()).thenReturn(Boolean.TRUE);
        when(mockPreparedStmnt.getGeneratedKeys()).thenReturn(mockResultSet);
        when(mockResultSet.next()).thenReturn(Boolean.TRUE, Boolean.FALSE);
        when(mockResultSet.getInt(Fields.GENERATED_KEYS)).thenReturn(userId);
    }

    @After
    public void tearDown() {
    }

    @Test
    public void testCreateWithNoExceptions() throws SQLException {

        UserDAO instance = new UserDAO(mockDataSource);
        instance.create(new User());

        //verify and assert
        verify(mockConn, times(1)).prepareStatement(anyString(), anyInt());
        verify(mockPreparedStmnt, times(6)).setString(anyInt(), anyString());
        verify(mockPreparedStmnt, times(1)).execute();
        verify(mockConn, times(1)).commit();
        verify(mockResultSet, times(2)).next();
        verify(mockResultSet, times(1)).getInt(Fields.GENERATED_KEYS);
    }

    @Test(expected = SQLException.class)
    public void testCreateWithPreparedStmntException() throws SQLException {

         //mock
         when(mockConn.prepareStatement(anyString(), anyInt())).thenThrow(new SQLException());


        try {
            UserDAO instance = new UserDAO(mockDataSource);
            instance.create(new User());
        } catch (SQLException se) {
            //verify and assert
            verify(mockConn, times(1)).prepareStatement(anyString(), anyInt());
            verify(mockPreparedStmnt, times(0)).setString(anyInt(), anyString());
            verify(mockPreparedStmnt, times(0)).execute();
            verify(mockConn, times(0)).commit();
            verify(mockResultSet, times(0)).next();
            verify(mockResultSet, times(0)).getInt(Fields.GENERATED_KEYS);
            throw se;
        }

    }
}

As far as I can tell this is a limitation / poor implementation. When looking at org.mockito.internal.matchers.CapturingMatcher there is

public boolean matches(Object argument) {
    return true;
}

meaning it matches every argument / class.

This results in org.mockito.internal.matchers.CapturingMatcher#getAllValues returning a List<B> but actually containing one A and one B resulting in a ClassCastException during runtime when trying to get them as B.

List<Object> arguments; // the invocations

// adds a new invocation
public void captureFrom(Object argument) {
    // ... 
    this.arguments.add(argument);
    // ... 
}

// return the list of arguments, using raw types remove any compiler checks for validity,
// the returned List contains elements that are not of type T
public List<T> getAllValues() {
    // ... 
    return new ArrayList<T>((List) arguments);
    // ... 
}

This should be solvable by changing org.mockito.ArgumentCaptor in a way that it passes its Class<? extends T> clazz into the CapturingMatcher and therefore passing the type information along properly, enabling a proper matches implementation and removing the need for the cast / raw type usage.

Don't mock Plugin if it's the class you want to Unit test. It's the opposite! Also for a unit test I would definitely avoid creating a spring context, instead you should only do that for integration testing or some very rare / specific case.

Anyway I suppose you want to test the interactions between the plugin and the manager. So you should definitely read the Mockito documentation but here's a first start that get a mocked manager injected in the plugin.

@RunWith(MockitoJUinitRunner.class)
public class PluginTest {
    @Mock DistributionManager mockedManager;
    @InjectMocks Plugin testedPlugin = new Plugin(); // initialization not need when using Mockito 1.9.x

    @Test public void plugin_should_call_the_the_manager_on_doSomething() {
        // given
        // when
        // then
    }

    // other scenarios
}

Please note, that you only need to use eihter the JUnit runner MockitoJUinitRunner.class or the utility class and method MockitoAnnotations.init(), but not both!

Other remarks:

• As you are using JUnit 4.x you don't need to make your test method name begin by test, as those are annotated by @Test you can name them as whatever you want that is readable and expressive on the intent of the test.
• Same goes for set up and tear down methods, as they are respectively annotated by @Before and @After you can describe what your setting up or tearing down.
• And finally, don't name your test class PluginTestCase, the suffix TestCase was only used for abstract classes that would be extended by an actual test suffixed by Test such as MyClassTest. And anyway Maven Surefire will look for classes named *Test.

First you need to create a mock m_contractsDao and set it up. Assuming that the class is ContractsDao:

ContractsDao mock_contractsDao = mock(ContractsDao.class);
when(mock_contractsDao.save(any(String.class))).thenReturn("Some result");

Then inject the mock into m_orderSvc and call your method.

m_orderSvc.m_contractsDao = mock_contractsDao;
m_prog = new ProcessOrdersWorker(m_orderSvc, m_opportunitySvc, m_myprojectOrgSvc);
m_prog.work(); 

Finally, verify that the mock was called properly:

verify(mock_contractsDao, times(1)).save("Parameter I'm expecting");

Usually when unit testing you want to mock all external dependencies of a class. That way the unit test can remain independent and focused on the class under test.

Nevertheless, if you want to mix Spring autowiring with Mockito mocks, an easy solution is to annotate with both @InjectMocks and @Autowired:

  @InjectMocks
  @Autowired
  private UploadServiceImpl uploadService;

The net effect of this is that first Spring will autowire the bean, then Mockito will immediately overwrite the mocked dependencies with the available mocks.

Mockito 1.10.5 has introduced this feature.

For the code sample in the question, here is one way to capture the varargs:

    ArgumentCaptor<String> varArgs = ArgumentCaptor.forClass(String.class);
    A mock = Mockito.mock(A.class);
    mock.setNames("Jeff", "Mike", "John");
    Mockito.verify(mock).setNames(varArgs.capture());

    //Results may be validated thus:
    List<String> expected = Arrays.asList("Jeff", "Mike", "John");
    assertEquals(expected, varArgs.getAllValues());

Please see the ArgumentCaptor javadoc for details.

I wanted to do the same thing, and eventually accomplished it by using the Mockito "spy" function, which wraps a real object with a mock object. All calls to the mock object get forwarded to the real object, except those you are trying to mock. For example:

ObjectMapper om = Mockito.spy(new ObjectMapper());
Mockito.when( om.writeValueAsString(ErrorObject.class)).thenThrow(new JsonProcessingException("") {});

All usages of om will be handled by the underlying ObjectMapper instance until an instance of ErrorObject gets passed in, at which point the JsonProcessingException will be thrown.

The newJsonProcessingException is created as an anonymous class, as it is a protected class and only a sub-class can be instantiated.

Assuming the following method to test:

public boolean doSomething(SomeClass arg);

Mockito documentation says that you should not use captor in this way:

when(someObject.doSomething(argumentCaptor.capture())).thenReturn(true);
assertThat(argumentCaptor.getValue(), equalTo(expected));

Because you can just use matcher during stubbing:

when(someObject.doSomething(eq(expected))).thenReturn(true);

But verification is a different story. If your test needs to ensure that this method was called with a specific argument, use ArgumentCaptor and this is the case for which it is designed:

ArgumentCaptor<SomeClass> argumentCaptor = ArgumentCaptor.forClass(SomeClass.class);
verify(someObject).doSomething(argumentCaptor.capture());
assertThat(argumentCaptor.getValue(), equalTo(expected));

To answer your second question first. If you're using JUnit 4, you can annotate your test with

@Test(expected=MyException.class)

to assert that an exception has occured. And to "mock" an exception with mockito, use

when(myMock.doSomething()).thenThrow(new MyException());