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

You can use Mockitos Answer.

doAnswer(new Answer() {
     @Override
     public Object answer(InvocationOnMock invocation) {
         Object[] args = invocation.getArguments();
         ByteArrayOutputStream baos = (ByteArrayOutputStream)args[0];
         //fill baos with data
         return null;
     }
 }).when(client).retrieveFile(baos);

However, if you have possibility to refactor the tested code, better is to make client return the OutputStream or some data that can be put to this Output stream. This is would be much better design.

Also, a slightly more terse way to get around this is to use the do syntax instead of when.

doReturn(User.class).when(methodParameter).getParameterType();

You can try the following idea (taken from similar discussion on github):

.doAnswer { throw ServiceException("Bad Request") }

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());

(This pretty much helped me figure it out)

Pretty simple solution (I almost had it right to begin with): I was missing a few PowerMockito dependency jars (from https://code.google.com/p/powermock/wiki/Downloads?tm=2): Specifically {cglib-nodep-2.2.2.jar, javssist-3.18.1-GA.jar, objenesis-2.1.jar}.

It was a simple solution and kinda dumb mistake to begin with in the 1st place, since that powerMock googleCode download page has all of them: At 1st, when I had the problem, I had only downloaded and added powermock-mockito-1.5.4-full.jar; I already had the JUnit & Mockito jars, so I think that set of 3 let me write PowerMock code without any compile errors in Eclipse. The googlecode download page has the powermockito jar + dependecies in a zip, but also said powerockito jar available alone too. That situation made it kinda hard to realize I was missing some others since it appeared I had all I need from that perspective (thought I already had the dependencies I needed per my existing JUnit and Mockito jars).

In actuality, the zip with dependencies had the additional ones I needed to solve the problem. I should have double-checked that 1st, but didn't realize I made the opposite bad assumption.

So... answer is to make sure to get the zip with all dependencies [and add them all to your buildpath]. Kinda obvious and dumb in my part in the end, but hey, a lot of software bugs and problems end up being that: Simple bad assumptions or overlooked details we don't realize we made, and therefore take a while to realize when troubleshooting...

You're misunderstanding what a mock is. When you're doing

MyClass myClass = Mockito.mock(MyClass.class);
// ...
assertNull(myClass.methodToTest(myObject));

You're not actually invoking methodToTest on your real object. You're invoking methodToTest on the mock, which by default, does nothing and return null, unless it was stubbed. Quoting from Mockito docs:

By default, for all methods that return value, mock returns null, an empty collection or appropriate primitive/primitive wrapper value (e.g: 0, false, ... for int/Integer, boolean/Boolean, ...).

This explains your subsequent error: the method was really not invoked on the mock.

It seems what you want here is a spy instead:

You can create spies of real objects. When you use the spy then the real methods are called (unless a method was stubbed).

A note of warning though: since it is the real methods that are getting called, you should not use Mockito.when but prefer Mockito.doReturn(...).when, otherwise the method will be called once for real. If you consider the expression:

Mockito.when(myClass.methodUsedInMethodBeingTested(Matchers.any(MyTypeParam.class))).thenReturn(Collections.<X, Y> emptyMap());
             ^-----------------------------------^
                 this will be invoked by Java

the argument of the method when must be evaluated, but this means the method methodUsedInMethodBeingTested will be invoked. And since we have a spy, it is the real method that will be invoked. So, instead, use:

MyClass spy = Mockito.spy(new MyClass());
Mockito.doReturn(Collections.<X, Y> emptyMap()).when(spy).methodUsedInMethodBeingTested(Matchers.any(MyTypeParam.class));
assertNull(spy.methodToTest(myObject));
Mockito.verify(spy).methodUsedInMethodBeingTested(Matchers.any(MyTypeParam.class));

If I were you, I would simply mock the services A and B and your executors, then inject them thanks to the annotation @InjectMocks as they are fields of your class.

If you want mock the method execute of your Executor, you should rather proceed as next to simply call the method run of the provided Runnable:

doAnswer(
    (InvocationOnMock invocation) -> {
        ((Runnable) invocation.getArguments()[0]).run();
        return null;
    }
).when(serviceAExecutorService).execute(any(Runnable.class));

So basically your test would be something like this:

@RunWith(MockitoJUnitRunner.class)
public class CompletableFutureServiceTest {

    // The mock of my service A
    @Mock
    private ServiceA ServiceA;
    // The mock of my service B
    @Mock
    private ServiceB ServiceB;
    // The mock of your executor for the service A
    @Mock
    private Executor serviceAExecutorService;
    // The mock of your executor for the service B
    @Mock
    private Executor serviceBExecutorService;
    // My class in which I want to inject the mocks
    @InjectMocks
    private CompletableFutureService service;

    @Test
    public void testSomeMethod() {
        // Mock the method execute to call the run method of the provided Runnable
        doAnswer(
            (InvocationOnMock invocation) -> {
                ((Runnable) invocation.getArguments()[0]).run();
                return null;
            }
        ).when(serviceAExecutorService).execute(any(Runnable.class));
        doAnswer(
            (InvocationOnMock invocation) -> {
                ((Runnable) invocation.getArguments()[0]).run();
                return null;
            }
        ).when(serviceBExecutorService).execute(any(Runnable.class));

        ServiceAResponse serviceAResponse = ... // The answer to return by service A
        // Make the mock of my service A return my answer
        when(ServiceA.retrieve(any(ServiceARequest.class))).thenReturn(
            serviceAResponse
        );
        ServiceBResponse serviceBResponse = ... // The answer to return by service B
        // Make the mock of my service B return my answer
        when(ServiceB.retrieve(any(ServiceBRequest.class))).thenReturn(
            serviceBResponse
        );

        // Execute my method
        ServiceResponse response = service.someMethod(
            new ServiceARequest(), new ServiceBRequest()
        );

        // Test the result assuming that both responses are wrapped into a POJO
        Assert.assertEquals(serviceAResponse, response.getServiceAResponse());
        Assert.assertEquals(serviceBResponse, response.getServiceBResponse());
    }
}

Actually, the old style of exception testing is to wrap a try block around the code that throws the exception and then add a fail() statement at the end of the try block. Something like this:

public void testNullParameter() {
    try {
        IPAddress addr = new IPAddress(null);
        fail("InvalidIPAddressException not thrown.");
    } catch(InvalidIPAddressException e) {
        assertNotNull(e.getMessage());
    }
}

This isn't much different from what you wrote but:

1. Your assertTrue(addr.getOctets() == null); is useless.
2. The intend and the syntax are clearer IMO and thus easier to read.

Still, this is a bit ugly. But this is where JUnit 4 comes to the rescue as exception testing is one of the biggest improvements in JUnit 4. With JUnit 4, you can now write your test like this:

@Test (expected=InvalidIPAddressException.class) 
public void testNullParameter() throws InvalidIPAddressException {
    IPAddress addr = new IPAddress(null);
}

Nice, isn't it?

Now, regarding the real question, if I don't expect an exception to be thrown, I'd definitely go for way #1 (because it's less verbose) and let JUnit handle the exception and fail the test as expected.

how about you create an anonymous exception of type JsonProcessingException

when(mapper.writeValueAsString(any(Object.class))).thenThrow(new JsonProcessingException("Error"){});

The {} braces does the trick. This is much better since it is not confusing to the reader of the test code.