How about

when( method-call ).thenReturn( value1, value2, value3 );

You can put as many arguments as you like in the brackets of thenReturn, provided they're all the correct type. The first value will be returned the first time the method is called, then the second answer, and so on. The last value will be returned repeatedly once all the other values are used up.

You seem to be after contradictory goals. On the one hand, you're trying to avoid writing data to disk, which isn't a bad goal in tests. On the other, you're trying to test your I/O-handling class, which means you'll be working with system utilities that assume that your File will work with native calls. As such, here's my guidance:

• Don't try to mock a File. Just don't. Too many native things depend on it.
• If you can, split your I/O-handling code into the half that opens a File and turns it into a Reader, and the half that parses HTML out of the Reader.
• At that point, you don't need a mock at all--just construct a StringReader to simulate the data source.
• While that handles your unit tests pretty well, you may also want to write an integration test that uses a temporary file and ensure that it reads right. (Thanks Brice for adding that tip!)

Don't be afraid to refactor your class to make testing easier, as here:

class YourClass {
  public int method(File file) {
    // do everything here, which is why it requires a mock
  }   
}   

class YourRefactoredClass {
  public int method(File file) {
    return methodForTest(file.getName(), file.isFile(),
        file.isAbsolute(), new FileReader(file));
  }   

  /** For testing only. */
  int methodForTest(
      String name, boolean isFile, boolean isAbsolute, Reader fileContents) {
    // actually do the calculation here
  }   
}   

class YourTest {
  @Test public int methodShouldParseBadHtml() {
    YourRefactoredClass yrc = new YourRefactoredClass();
    assertEquals(42, yrc.methodForTest(
        "bad.html", true, false, new StringReader(badHTMLText));
  }   
}   

At this point the logic in method is so straightforward it's not worth testing, and the logic in methodForTest is so easy to access that you can test it heavily.

Some of the other answers offer alternatives to doing exactly what I want here, but this is doable by Spying the Consumer class itself and having the spy call the method you really want to execute. A helper method for wrapping the lambda to create the spy helps here:

/** Get a spied version of the given Consumer. */
private Consumer<Item> itemHandlerSpy(Consumer<Item> itemHandler) {
  // Create a spy of the Consumer functional interface itself.
  @SuppressWarnings("unchecked")
  Consumer<Item> spy = (Consumer<Item>) Mockito.spy(Consumer.class);
  // Tell the spy to run the given consumer when the Consumer is given something to consume. 
  Mockito.doAnswer(it -> {
    // Get the first (and only) argument passed to the Consumer.
    Item item = (Item) it.getArguments()[0];
    // Pass it to the real consumer so it gets processed.
    itemHandler.accept(item);
    return null;
  }).when(spy).accept(Mockito.any(Item.class));
  return spy;
}

And then the test method becomes very straightforward:

Consumer<Item> itemHandler = itemHandlerSpy(Item::foo);
instance.conditionalRun(itemHandler);
// This verifies conditionalRun called the Consumer exactly once.
Mockito.verify(itemHandler).accept(Mockito.any(Item.class));

I have found the problem.

The TestRunner I was using was the correct one (JUnit 4), however, I declared my test class as:

public class CommandTest extends TestCase

Which I assume is causing the test runner to treat it as a JUnit 3 test. I removed extends TestCase and received the expected results.

You can use a Mockito Spy for this. If you setup anotherObj as a spy you can verify method calls on that object. In your example you need to make sure that the call to foo uses the spy instead of an ordinary implementation of anotherObj. The spy is setup something like this:

AnotherClass anotherObjSpy = Mockito.spy(new AnotherClass());
// do stuff -- e.g. anotherObjSpy.foo(...);
verify(anotherObjSpy).codePath1(...);

For Java users

Based on the WireMock docs.

There are 3 possibilities to use WireMock in your tests :

1. If you are using Wiremock as JUnit 4 rule to configure the port use :

import static com.github.tomakehurst.wiremock.core.WireMockConfiguration.wireMockConfig;

...

@Rule
public WireMockRule wireMockRule = new WireMockRule(wireMockConfig().port(8888));

2. If you are using new instance and start it from your Test class (for example @Before) :

import static com.github.tomakehurst.wiremock.core.WireMockConfiguration.options;

...

public class Test {

    WireMockServer wm;

    @BeforeEach
    void setUp() {
        wm = new WireMockServer(options().port(8888));
        wm.start();
    }

    @Test
    void test() {
        wm.stubFor(...);
    }
}

3. With static configuration of default instance (not using new instance in your test) :

WireMock.configureFor(8888);

For Kotlin users

If you are using kotlin you can add actual wiremock instance to stubFor and verify calls like wm.stubFor() and configure the port like in option 3 of this answer.

According to the Mockito documentation, you can make a mock serializable:

List serializableMock = mock(List.class, withSettings().serializable());

Technically speaking both "mocks" and "spies" are a special kind of "test doubles".

Mockito is unfortunately making the distinction weird.

A mock in mockito is a normal mock in other mocking frameworks (allows you to stub invocations; that is, return specific values out of method calls).

A spy in mockito is a partial mock in other mocking frameworks (part of the object will be mocked and part will use real method invocations).

There is no need to mock primitive classes like Future and Optional. Just wrap the mocked data you want to return inside a real Optional:

MyData myData = Mockito.mock(MyData.class)
when(repository.getData()).thenReturn(Optional.of(myData));

For mocking absence:

when(repository.getData()).thenReturn(Optional.<MyData>empty());