How to use allows_initializing_mocks_manually method of org.mockitousage.session.MockitoSessionTest class

Since none of your classes are final, you can use "pure mockito" without resorting to PowerMockito:

final CacheWrapper wrapper = Mockito.spy(new CacheWrapper());

Mockito.doThrow(something)
    .when(wrapper).putInSharedMemory(Matchers.any(), Matchers.any());

Note that "method arguments" to a stub are in fact argument matchers; you can put specific values (if not "surrounded" by a specific method it will make a call to .equals()). So, you can guide the stub's behavior differently for different arguments.

Also, no need for any kind of .replay() with Mockito, which is very nice!

Finally, be aware that you can doCallRealMethod() as well. After that, it depends on your scenarios...

(note: last mockito version available on maven is 1.10.17 FWIW)

According to https://groups.google.com/forum/?fromgroups#!topic/mockito/9WUvkhZUy90, you should rephrase your

when(bar.getFoo()).thenReturn(fooBar)

to

doReturn(fooBar).when(bar).getFoo()

You can create a file as part of the test, no need to mock it out.

JUnit does have a nice functionality for creating files used for testing and automatically cleaning them up using the TemporaryFolder rule.

public class MyTestClass {

    @Rule
    public TemporaryFolder folder = new TemporaryFolder();

    @Test
    public void myTest() {
        // this folder gets cleaned up automatically by JUnit
        File file = folder.newFile("someTestFile.txt");

        // populate the file
        // run your test
    }
}

All warnings go away when alternative way of mock specification is used:

    ScheduledFuture<?> future = Mockito.mock(ScheduledFuture.class);
    Mockito.doReturn(future).when(executor).schedule(
        Mockito.any(Runnable.class),
        Mockito.anyLong(),
        Mockito.any(TimeUnit.class)
    );

MockitoJUnitRunner gives you automatic validation of framework usage, as well as an automatic initMocks().

The automatic validation of framework usage is actually worth having. It gives you better reporting if you make one of these mistakes.

• You call the static when method, but don't complete the stubbing with a matching thenReturn, thenThrow or then. (Error 1 in the code below)

• You call verify on a mock, but forget to provide the method call that you are trying to verify. (Error 2 in the code below)

• You call the when method after doReturn, doThrow or doAnswer and pass a mock, but forget to provide the method that you are trying to stub. (Error 3 in the code below)

If you don't have validation of framework usage, these mistakes are not reported until the following call to a Mockito method. This might be

• in the same test method (like error 1 below),
• in the next test method (like error 2 below),
• in the next test class.

If they occur in the last test that you run (like error 3 below), they won't be reported at all.

Here's how each of those types of errors might look. Assume here that JUnit runs these tests in the order they're listed here.

@Test
public void test1() {

    // ERROR 1
    // This compiles and runs, but it's an invalid use of the framework because 
    // Mockito is still waiting to find out what it should do when myMethod is called.
    // But Mockito can't report it yet, because the call to thenReturn might 
    // be yet to happen.
    when(myMock.method1());

    doSomeTestingStuff();

    // ERROR 1 is reported on the following line, even though it's not the line with
    // the error.
    verify(myMock).method2();

}

@Test
public void test2() {

    doSomeTestingStuff();

    // ERROR 2
    // This compiles and runs, but it's an invalid use of the framework because
    // Mockito doesn't know what method call to verify.  But Mockito can't report 
    // it yet, because the call to the method that's being verified might 
    // be yet to happen.
    verify(myMock);
}

@Test
public void test3() {

    // ERROR 2 is reported on the following line, even though it's not even in 
    // the same test as the error.
    doReturn("Hello").when(myMock).method1();


    // ERROR 3
    // This compiles and runs, but it's an invalid use of the framework because
    // Mockito doesn't know what method call is being stubbed.  But Mockito can't 
    // report it yet, because the call to the method that's being stubbed might 
    // be yet to happen.

    doReturn("World").when(myMock);

    doSomeTestingStuff(); 

    //  ERROR 3 is never reported, because there are no more Mockito calls. 
}

Now when I first wrote this answer more than five years ago, I wrote

So I would recommend the use of the MockitoJUnitRunner wherever possible. However, as Tomasz Nurkiewicz has correctly pointed out, you can't use it if you need another JUnit runner, such as the Spring one.

My recommendation has now changed. The Mockito team have added a new feature since I first wrote this answer. It's a JUnit rule, which performs exactly the same function as the MockitoJUnitRunner. But it's better, because it doesn't preclude the use of other runners.

Include

@Rule 
public MockitoRule rule = MockitoJUnit.rule();

in your test class. This initialises the mocks, and automates the framework validation; just like MockitoJUnitRunner does. But now, you can use SpringJUnit4ClassRunner or any other JUnitRunner as well. From Mockito 2.1.0 onwards, there are additional options that control exactly what kind of problems get reported.

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?

You shouldn't do this. Mockito is a really well-designed, simple to learn, extremely well-documented, and almost de-facto standard framework. And it's type-safe and doesn't need reflection, which makes tests easy to read and understand.

Let your developers learn the real Mockito and use its API directly. They'll be happy to use it because it will have a better, easier to use and more flexible design than your own super-api, and they'll know that they won't learn Mockito for nothing because they'll probably use it in other projects or even other jobs.

Mockito doesn't need another proprietary API on top of it. My suggested alternative is thus to forget about this and teach Mockito to your developers.

Check this issue

This seems to happen when a mock is created at instantation time.

If I set up my mocks in an @Before method the issue goes away.

Mockito uses CGLib to generate class object. However to instantiate this class object it uses Objenesis http://objenesis.org/tutorial.html

Objenesis is able to instantiate object without constructor using various techniques (i.e. calling ObjectStream.readObject and similar).