How to use getTarget method of org.mockito.internal.verification.OnlyTest class

Mockito can handle chained stubs:

Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);

// note that we're stubbing a chain of methods here: getBar().getName()
when(mock.getBar().getName()).thenReturn("deep");

// note that we're chaining method calls: getBar().getName()
assertEquals("deep", mock.getBar().getName());

AFAIK, the first method in the chain returns a mock, which is set up to return your value on the second chained method call.

Mockito's authors note that this should only be used for legacy code. A better thing to do otherwise is to push the behavior into your CacheContext and provide any information it needs to do the job itself. The amount of information you're pulling from CacheContext suggests that your class has feature envy.

Short answer: Use doReturn().when() instead of when().then()

Long answer can be found over here: How do Mockito matchers work?

Matchers return dummy values such as zero, empty collections, or null. Mockito tries to return a safe, appropriate dummy value, like 0 for anyInt() or any(Integer.class) or an empty List for anyListOf(String.class). Because of type erasure, though, Mockito lacks type information to return any value but null for any()

NullPointerException or other exceptions: Calls to when(foo.bar(any())).thenReturn(baz) will actually call foo.bar(null), which you might have stubbed to throw an exception when receiving a null argument. Switching to doReturn(baz).when(foo).bar(any()) skips the stubbed behavior.

Side Note: This issue could also be described something like, How to use Mockito matchers on methods that have precondition checks for null parameters?

Since Mockito 2.20 it is also possible, to add lenient() locally

@ExtendWith(MockitoExtension.class)
public class MockitoExample {

  static abstract class TestClass {
    public abstract int booleanMethod(boolean arg);
  }

  @Mock
  TestClass testClass;

  @BeforeEach
  public void beforeEach() {
    lenient().when(testClass.booleanMethod(eq(true))).thenReturn(1);
    lenient().when(testClass.booleanMethod(eq(false))).thenReturn(2);
  }

  @Test
  public void test() {
    assertEquals(1,testClass.booleanMethod(true));
    assertEquals(2,testClass.booleanMethod(false));
  }
}

In this sort of situation, I would use physical files for testing the component and not rely on a mocking framework. As fge mentions it may be easier plus you don't have to worry about any incorrect assumptions you may make of your mock.

For instance, if you rely upon File#listFiles() you may have your mock return a fixed list of Files, however, the order they are returned in is not guaranteed - a fact you may only discover when you run your code on a different platform.

I would consider using JUnit's TemporaryFolder rule to help you set up the file and directory structure you need for your test, e.g.:

public class DummyFileClassTest {
    @Rule
    public TemporaryFolder folder = new TemporaryFolder();

    @Test
    public void someMethod() {
        // given
        final File file1 = folder.newFile("myfile1.txt");
        final File file2 = folder.newFile("myfile2.txt");

        ... etc...
    }
}

The rule should clean up any created files and directories when the test completes.

Well, it turns out I was wrong. Mockito uses CGLib and Objenesis to create the Object. If you follow that link it explains how it does not call the super class constructor.

This is easily tested with the following code:

public class Test
  public Test() {
    // Never called.
    System.out.println("Constructor was called.");
  }

  public static void main(String[] args) {
    Test test = mock(Test.class);
  }

Take a look at the Mockito API docs. As the linked document mentions (Point # 12) you can use any of the doThrow(),doAnswer(),doNothing(),doReturn() family of methods from Mockito framework to mock void methods.

For example,

Mockito.doThrow(new Exception()).when(instance).methodName();

or if you want to combine it with follow-up behavior,

Mockito.doThrow(new Exception()).doNothing().when(instance).methodName();

Presuming that you are looking at mocking the setter setState(String s) in the class World below is the code uses doAnswer method to mock the setState.

World mockWorld = mock(World.class); 
doAnswer(new Answer<Void>() {
    public Void answer(InvocationOnMock invocation) {
      Object[] args = invocation.getArguments();
      System.out.println("called with arguments: " + Arrays.toString(args));
      return null;
    }
}).when(mockWorld).setState(anyString());

Mocks that return have the expectation that the return type matches the mocked object's return type.

Here's the mistake:

Mockito.when(remoteStore.get("a", "b")).thenReturn("lol");

"lol" isn't an Optional<String>, so it won't accept that as a valid return value.

The reason it worked when you did

Optional<Object> returnCacheValue = Optional.of((Object) returnCacheValueString);
Mockito.<Optional<Object>>when(remotestore.get("cache-name", "cache-key")).thenReturn(returnCacheValue);

is due to returnCacheValue being an Optional.

This is easy to fix: just change it to an Optional.of("lol") instead.

Mockito.when(remoteStore.get("a", "b")).thenReturn(Optional.of("lol"));

You can also do away with the type witnesses as well. The result above will be inferred to be Optional<String>.

You may refactor your code a little bit. In the "Working with Legacy Code" book by Martin Fowler, he describes a technique of separating the external API (think Java Mail API) from your own application code. The technique is called "Wrap and Skin" and is pretty simple.

What you should do is simply:

1. Create an interface MySession (which is your own stuff) by extracting methods from the javax.mail.Session class.
2. Implement that interface by creating a concrete class (looking a bit like the original javax.mail.Session)
3. In each method DELEGATE the call to equivalent javax.mail.Session method
4. Create your mock class which implements MySession :-)
5. Update your production code to use MySession instead of javax.mail.Session

Happy testing!

EDIT: Also take a look at this blog post: http://www.mhaller.de/archives/18-How-to-mock-a-thirdparty-final-class.html

You may have some trouble with any or argThat for primitive-type arguments to when and verify. Those Object-centric methods do their work with side-effects correctly, but they tend to return null for a dummy return value, which doesn't work for Java unwrapping primitives via auto-boxing.

Luckily, the org.mockito.ArgumentMatchers class has a full complement of primitive-centric methods (of which I've listed the int methods here):

static int anyInt()
static int eq(int value)
static int intThat(org.hamcrest.ArgumentMatcher<java.lang.Integer> matcher)

See all of them at the documentation for the ArgumentMatchers class.