How to use regular_failing_test method of org.mockitoutil.SafeJUnitRuleTest class

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?

I think you might need to do a little bit of refactoring. You can create mocks of static methods by creating a MockedStatic variable at class level and use that in your tests and also sometimes it needs to be closed in the @After block, something like

MockedStatic<StaticClass> mockedStaticClass;
@Before
public void setUp()
{
  mockedStaticClass = Mockito.mockStatic(StaticClass.class);
}

@After
public void tearDown() throws Exception
{
  mockedStaticClass.close();
}

@Test
public void yourTest()
{
  //make use of mockedStatic variable you created earlier
}

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.

I downloaded your code and got it working locally, as long as I included the relevant import statements:

import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.junit.runner.RunWith;
import org.junit.Test;
...

Perhaps you're missing an import somewhere.

You have a servlet implementation that uses the ServletContext, e.g.

public class SomeServlet extends HttpServlet{

    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        ServletContext servletContext = getServletContext();
        Object attribute = servletContext.getAttribute("test");
        System.out.println(attribute.toString());
   }
}

in this case you have 2 options to test the doGet method

Use powermock's partitial mocking to only mock the getServletContext method.

@RunWith(PowerMockRunner.class)
public class SomeServletTest {

    @Test
    public void onGet() throws ServletException, IOException{
        SomeServlet someServlet = PowerMock.createPartialMock(SomeServlet.class, "getServletContext");   
        ServletContext servletContext = PowerMock.createNiceMock(ServletContext.class);
        HttpServletRequest httpServletRequest = PowerMock.createNiceMock(HttpServletRequest.class);
        HttpServletResponse httpServletResponse = PowerMock.createNiceMock(HttpServletResponse.class);

        someServlet.getServletContext();
        PowerMock.expectLastCall().andReturn(servletContext);

        servletContext.getAttribute("test");
        PowerMock.expectLastCall().andReturn("hello");

        PowerMock.replay(someServlet, servletContext, httpServletRequest, httpServletResponse);

        someServlet.doGet(httpServletRequest, httpServletResponse);
    }
}

or a simpler way is to just override the getServletContext method. In this case you don't need powermock. You can just do it using easymock. e.g.

public class SomeServletTest {

    @Test
    public void onGet() throws ServletException, IOException{
        HttpServletRequest httpServletRequest = EasyMock.createNiceMock(HttpServletRequest.class);
        HttpServletResponse httpServletResponse = EasyMock.createNiceMock(HttpServletResponse.class);
        final ServletContext servletContext = EasyMock.createNiceMock(ServletContext.class);
        SomeServlet someServlet = new SomeServlet(){
            public ServletContext getServletContext() {
                return servletContext; // return the mock
            }
        };

        EasyMock.expect(servletContext.getAttribute("test")).andReturn("hello");
        EasyMock.replay(servletContext, httpServletRequest, httpServletResponse);

        someServlet.doGet(httpServletRequest, httpServletResponse);
    }
}

there can be 100's. like initialContext.lookup() also dependent on container.

In this case you can either create an InitialContext mock and use this. If your code creates a new InitialContext, e.g.

public void someMethod(){
    InitialContext context = new InitialContext();
    context.lookup(....);
}

you can simply extract the InitialContext instantiation to a protected method that you can override in your tests like I showed above with the ServletContext

public void someMethod(){
    InitialContext context = createInitialContext();
    context.lookup(....);
}

protected InitialContext createInitialContext(){
    return new InitialContext(); // can be overridden by a subclass 
                                 // and therefore by tests as well to
                                 // return a mock
}

If you don't want or you can't modify the code in this way, then you can use Powermock to intercept the constructor.

EDIT

Can you post your Mockito code? It would be a pleasure, since the methods are named differently.

@Test
public void onGet() throws ServletException, IOException {
  HttpServletRequest httpServletRequest = Mockito.mock(HttpServletRequest.class);
  HttpServletResponse httpServletResponse = Mockito.mock(HttpServletResponse.class);
  final ServletContext servletContext = Mockito.mock(ServletContext.class);
  SomeServlet someServlet = new SomeServlet(){
    public ServletContext getServletContext() {
      return servletContext; // return the mock
    }
  };

  Mockito.doReturn("hello").when(servletContext).getAttribute("test");

  someServlet.doGet(httpServletRequest, httpServletResponse);
}

In my case, I had a similar issue when I worked with JUnit5

@ExtendWith(MockitoExtension.class)
class MyServiceTest {
...

@InjectMocks
MyService underTest;

@Test
void myMethodTest() {
...
}

underTest was null. The cause of the problem was that I used @Test from JUnit4 package import org.junit.Test; instead JUnit5 import org.junit.jupiter.api.Test;

The response by david-wallace explains why you run into an OOM: a mock object is remembering details of every invocation.

But an equally important question is: now what to do about it? In addition to what David already suggested, the latest Mockito versions 1.10.19 as well as upcoming 2.0.x now support so-called stubOnly mocks (see javadoc):

stubOnly: A stub-only mock does not record method invocations, thus saving memory but disallowing verification of invocations.

Scala usage example:

import org.mockito.Mockito
val list = Mockito.mock(classOf[Foo], Mockito.withSettings().stubOnly())

// The syntax is a bit more concise when using ScalaTest's MockitoSugar
val foo = mock[Foo](Mockito.withSettings().stubOnly())

Java usage example (untested):

import org.mockito.Mockito;
Foo mock = Mockito.mock(Foo.class, Mockito.withSettings().stubOnly());

I'll leave this here for future reference and to be able to elaborate a bit more, even though I've answered in the comments.

What you're trying to accomplish is to put the stream in the onError flow. Unfortunately, by mocking it like this:

Mockito.`when`(apiManager.getPlacesPagedObservable(
                   Mockito.anyString(), Mockito.anyInt()))
                           .thenThrow(Exception(EXCEPTION_MESSAGE1))

You're actually telling Mockito to setup your mock in a way that just calling apiManager.getPlacesPagedObservable(anystring, anystring) should thrown an exception.

It is indeed true that throwing an exception inside an Rx stream will cause the entire stream to stop and end up in the onError method. However, this is exactly the problem with the approach you're using. You're not inside the stream when the exception is thrown.

Instead what you want to do is tell Mockito that once you call apiManager.getPlacesPagedObservable(anystring, anystring) you want to return a stream that will end up in the onError. This can be easily achieved with Observable.error() like so:

Mockito.`when`(apiManager.getPlacesPagedObservable(
               Mockito.a‌​nyString(), Mockito.anyInt()))
                    .thenReturn(Observable.error(
                                Exception(EXCEPTION_MESSAGE1)))

(It might be possible that you need to add some type information in this part here Observable.error(), you might also need to use something else instead of an observable - single, completable, etc.)

The mocking above will tell Mockito to setup your mock to return an observable that will error as soon as it's subscribed to. This will in turn put your subscriber directly in the onError stream with the specified exception.

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.