How to use enableClassCache method of org.mockito.configuration.IMockitoConfiguration class

You need to inject mock inside the class you're testing. At the moment you're interacting with the real object, not with the mock one. You can fix the code in a following way:

void testAbc(){
     myClass.myObj = myInteface;
     myClass.abc();
     verify(myInterface).myMethodToBeVerified(new String("a"), new String("b"));
}

although it would be a wiser choice to extract all initialization code into @Before

@Before
void setUp(){
     myClass = new myClass();
     myClass.myObj = myInteface;
}

@Test
void testAbc(){
     myClass.abc();
     verify(myInterface).myMethodToBeVerified(new String("a"), new String("b"));
}

If you are willing to use Spring test util, it's fairly easy with org.springframework.test.util.ReflectionTestUtils.

MappingDef mappingDef = Mappers.getMapper(MappingDef.class);
MappingUtils mappingUtils = Mappers.getMapper(MappingUtils.class);

...

// Somewhere appropriate
@Before
void before() {
    ReflectionTestUtils.setField(
        mappingDef,
        "mappingUtils",
        mappingUtils
    )
}

So for me the first thing you need to do is to extract the part of the code that can throw a ClassNotFoundException in order to be able to easily mock it, something like:

public Class<? extends NetworkResponseBuilder> getNetworkResponseBuilderClass()
    throws ClassNotFoundException {
    // Your logic here
}

Then you can test a real factory instance using Mockito.spy to be able to redefine the behavior of the method getNetworkResponseBuilderClass() as next:

public void testFactoryIfNetworkResponseBuilderNotFound() {
    Factory factory = spy(new Factory());
    when(factory.getNetworkResponseBuilderClass()).thenThrow(
        new ClassNotFoundException()
    );
    // The rest of your test here
}

public void testFactoryIfNetworkResponseBuilderFound() {
    Factory factory = spy(new Factory());
    when(factory.getNetworkResponseBuilderClass()).thenReturn(
        OkHttpNetworkResponse.Builder.class
    );
    // The rest of your test here
}

More details about Mockito.spy.

ServletRequest, ServletResponse and FilterChain are all interfaces, so you can easily create test stubs for them, either by hand or using a mocking framework.

Make the mock objects configurable so that you can prepare a canned response to getRequestURI() and so that you can query the ServletResponse to assert that sendRedirect has been invoked.

Inject a mock ModeService.

Invoke doFilter passing the mock ServletRequest, ServletResponse and FilterChain as its parameters.

@Test
public void testSomethingAboutDoFilter() {
    MyFilter filterUnderTest = new MyFilter();
    filterUnderTest.setModeService(new MockModeService(ModeService.ONLINE));
    MockFilterChain mockChain = new MockFilterChain();
    MockServletRequest req = new MockServletRequest("/maintenance.jsp");
    MockServletResponse rsp = new MockServletResponse();

    filterUnderTest.doFilter(req, rsp, mockChain);

    assertEquals("/maintenance.jsp",rsp.getLastRedirect());
}

In practice you'll want to move the setup into an @Before setUp() method, and write more @Test methods to cover every possible execution path.

... and you'd probably use a mocking framework like JMock or Mockito to create mocks, rather than the hypothetical MockModeService etc. I've used here.

This is a unit testing approach, as opposed to an integration test. You are only exercising the unit under test (and the test code).

The following, running under Mockito 1.9.0 and JUnit 4.8.2, does not print anything to my console:

import static org.mockito.Mockito.*;

import org.junit.Test;

public class TestNonCall {
  public class TestClass {
    public String test() {
      System.out.println("test called!");
      return "test";
    }
  }

  @Test
  public void doTest() {
    final TestClass mock = mock(TestClass.class);

    when(mock.test()).thenReturn("mock!");
  }
}

Further, if I put a breakpoint in the test() method it is never hit.

Perhaps post more code? It looks like your example is not complex enough to demonstrate the behaviour you're having problems with.

Also: are you using the latest version of Mockito?

Edit: New Thought: Are You Mocking a Final Method?

If you add a final modifier to the method you are mocking, you get the behaviour you reported.

This is because Mockito does not mock final and static methods. Instead, it delegates the calls to the real implementation.

Might your actual code be attempting to mock a final method?

If so, you can use PowerMock, which is an extension to Mockito that allows mocking final methods.

You would need to add the following annotations to your test case class:

@RunWith(PowerMockRunner.class)
@PrepareForTest(TestClass.class)
public class TestNonCall {
  // ...
}

and mock the class using the PowerMock method in your test method:

final TestClass mock = PowerMockito.mock(TestClass.class);

then proceed as usual.

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

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 got around this by upgrading to the latest version of mockito. Currently it is:

testImplementation "org.mockito:mockito-core:2.25.1"

After that I had some build errors which was resolved by selecting

File->Invalidate Caches / Restart...

I would stub that Provider and make it return the prototypeMock every time using the @Before method invoked before each of the tests:

@Mock
private javax.inject.Provider<MyPrototype> prototypeFactoryStub;

@Mock 
MyPrototype prototypeMock;

@InjectMocks 
MySingleton sut;

@Before
public void init(){
   MockitoAnnotations.initMocks(this); // optional

   when(prototypeFactoryStub.get()).thenReturn(prototypeMock);
}

@Test
public void testPrototype() {
    sut.doStuff();
    verify(prototypeMock, times(1)).invoke();
}

I have written an article on Mockito Stubbing if you need a further read.