How to use runInMultipleThreads method of org.concurrentmockito.ThreadsShareAMockTest class

The easiest way may be to combine Mockitos Answer with lambdas, streams and iterators. The resulting code is

Iterator<Integer> values = Stream.iterate(0, n -> n + 100).iterator();
when(myClass.myMethod()).thenAnswer(i -> values.next());

The code can be made a little more efficient if you use an IntStream and a PrimitiveIterator.OfInt as the iterator type, but that is probably overkill for a unit test...

For some reason, your test suite, tries to load the MockitoJunitRunner from the org.mockito.junit contained in the Mockito versions >= 2. O. In that version, the line:

at org.mockito.junit.MockitoJUnitRunner.<init>(MockitoJUnitRunner.java:152)

is doing this:

public MockitoJUnitRunner(Class<?> klass) throws InvocationTargetException {
        //by default, StrictRunner is used. We can change that potentially based on feedback from users
        this(new StrictRunner(new RunnerFactory().createStrict(klass), klass));
    }

and the RunnerFactory that is loaded here is from version 1.x as createStrict has been introduced in Mockito 2.x.

So go through the pom dependency tree and to find what artifact implicitly add the Mockito 2.x dependency to your project and exclude it.

Alternatively.. as a workaround, instead of the @RunWith(MockitoJUnitRunner.class) you can use:

@Before
public void init() {
    MockitoAnnotations.initMocks(this);
}

You can also check out this Mockito cheat sheet to keep all the standards at hand.

If you want to do a pure unit test then for the line

service.getJdbcTemplate().query("....");

You will need to mock the Service, then the service.getJdbcTemplate() method to return a mock JdbcTemplate object, then mock the query method of mocked JdbcTemplate to return the List you need. Something like this:

@Mock
Service service;

@Mock
JdbcTemplate jdbcTemplate;


@Test
public void testGetUserNames() {

    List<String> userNames = new ArrayList<String>();
    userNames.add("bob");

    when(service.getJdbcTemplate()).thenReturn(jdbcTemplate);
    when(jdbcTemplate.query(anyString(), anyObject()).thenReturn(userNames);

    String retVal = Class.getUserNames("test");
    assertEquals("bob", retVal);
}

The above doesn't require any sort of Spring support. If you were doing an Integration Test where you actually wanted to test that data was being pulled from a DB properly, then you would probably want to use the Spring Test Runner.

ExpectedException works by wrapping your entire test method in a try-catch block via a JUnit @Rule. When your code throws an exception, it goes up the stack to the nearest try/catch, which happens to be in the ExpectedException instance (which checks that it is the exception you're expecting).

In Java, if an uncaught exception occurs in a method, control will never return to statements later in that method. The same rules apply here: Control never returns to the statements in your test after the exception.

Technically, you could put the verifications in a finally block, but that tends to be a bad habit. EDIT: Your system-under-test might throw an unexpected exception, or no exception at all, which would give you a helpful failure message and trace; however, if that failure then causes your verifications or assertions to fail in the finally block, then Java will show that rather than a message about the unexpected exception or unexpected success. This can make debugging difficult, especially because your error will come from lines of code following the root cause of the error, incorrectly implying that the code above it succeeded.

If you really need to verify state after the exception, on a per-method basis, you can always revert back to this idiom:

@Test
public void testExpectedException()
{
  MockedObject mockObj = mock(MockedObj.class);
  MySubject subject = new MySubject(mockedObj);
  try {
    subject.someMethodThrowingException();
    fail("Expected MyException.");
  } catch (MyException expected) {
    assertEquals("My exception message.", expected.getMessage());
  }
  verify(mockObj).someCleanup(eq(...));
}

Update: With Java 8's lambda expressions, you can wrap a functional interface call in a try block concisely enough to be useful. I imagine support for this syntax will find its way into many standard testing libraries.

assertThrows(MyException.class,
    () -> systemUnderTest.throwingMethod());

I think this happens because mockito doesn't know the semantic meaning of isEmpty() and when it encounters a boolean method mocks it with a default value that is false. Same think happens with size() but the default value here is 0.

Basically, you need to define the expected behaviour of your mocked object. If you don't, it will return default values.

You have to use PowerMock and Mockito together.

I don't understand what your code snippet is trying to do, but the following snippets allow the static getInstance() method of the Calendar class to return a mocked Calendar Object. Maybe that'll point you in the right direction

At the class level:

@RunWith(PowerMockRunner.class)
@PrepareForTest(Calendar.class)
public class XXXXXX {

In your test method:

PowerMockito.mockStatic(Calendar.class);
    Calendar calendar = mock(Calendar.class);
    when(calendar.get(eq(Calendar.HOUR_OF_DAY))).thenReturn(3);

    Mockito.when(Calendar.getInstance()).thenReturn(calendar);

I used a spy for the self same exercise:

#13

I changed my SniperListener mock into a spy thus:

private final SniperListener sniperListenerSpy = spy(new SniperListenerStub());
private final AuctionSniper sniper = new AuctionSniper(auction, sniperListenerSpy);

And also created a stubbed implementation of SniperListener:

private class SniperListenerStub implements SniperListener {
    @Override
    public void sniperLost() {
    }

    @Override
    public void sniperBidding() {
        sniperState = SniperState.bidding;
    }

    @Override
    public void sniperWinning() {
    }
}

The book uses JMock's "States", but I used a nested enum instead:

private SniperState sniperState = SniperState.idle;

private enum SniperState {
    idle, winning, bidding
}

You then have to use regular JUnit asserts to test for the state:

@Test
public void reportsLostIfAuctionClosesWhenBidding() {
    sniper.currentPrice(123, 45, PriceSource.FromOtherBidder);
    sniper.auctionClosed();
    verify(sniperListenerSpy, atLeastOnce()).sniperLost();
    assertEquals(SniperState.bidding, sniperState);
}

You need a Method object and a Class object. As per your comment, Mockito cannot mock a Method, so you'll need a real one. I haven't tested this, but I believe this would work. Instead of:

when(mockContext.getMethod().getName()).thenReturn("someMethod");
when(mockContext.getMethod().getDeclaringClass().getName()).thenReturn("someClass");

You need:

// any method will do, but here is an example of how to get one.
Method testMethod = this.getClass().getMethod("logCallTest");

when(mockContext.getMethod()).thenReturn(testMethod);

Obviously, getName() will not return "someMethod" anymore and getDeclaringClass().getName() will return the name of this test class (in the example), but although you couldn't pick what they return, what they return is still deterministic, so you should be able to verify anything you need. (Of course, if you needed to spy or verify that a call was made on the Method object itself, you're still stuck.)

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.