This is a long time ago question, but here is how i did it, using Mockito spy, create a method which call the parent method in the child class:

public class Child extends Parent {
    /**
     * Shouldn't invoke protected Parent.print() of parent class.
     */
    @Override
    protected String print() {
        // some additional behavior
    return callParent();
    }

    protected callParent()
    {
      super.print();
    }

}

And in the test :

@Test
public void sould_mock_invocation_of_protected_method_of_parent_class() throws Exception {

    // Given
    Child child = Mockito.spy(new Child());
    Mockito.doReturn(null)
           .when(child)
           .callParent();
    // When
    String retrieved = child.print();

    // Then
    Mockito.verify(child, times(1)).callParent(); // verification of child method
    Assert.assertEquals(retrieved, "abc");
}

Note: this test only check we call the parent method in the child class

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.

Try to add @PowerMockIgnore("org.apache.http.conn.ssl.*") annotation to your class

It's a bug: https://github.com/spring-projects/spring-boot/issues/6541

The fix is in spring-data 1.0.2-SNAPSHOT and 2.0.3-SNAPSHOT : https://github.com/arangodb/spring-data/issues/14#issuecomment-374141173

If you aren't using these version, you can work around it by declaring the mock with its name:

@MockBean(name="myMongoRepository")
private MyMongoRepository repository;

In response to your comment

From Spring's doc:

For convenience, tests that need to make REST calls to the started server can additionally @Autowire a TestRestTemplate which will resolve relative links to the running server.

Reading this, I think you need to declare @SpringBootTest with a web environment:

@SpringBootTest(webEnvironment=WebEnvironment.RANDOM_PORT)

If your spring boot doesn't start the web environment, then what is the need for TestRestTemplate. Thus, I guess spring does not even make it available.

(Slight disclaimer, I've never done this personally, just read about it in the javadoc)... If all of your methods on your mock interface would be ok with the same default behaviour, you could set the default answer on your mock in a manner like:

Foo myMock = Mockito.mock(Foo.class,new ThrowsExceptionClass(IllegalArgumentException.class));
Mockito.when(myMock.doSomething(Matchers.eq("1"))).thenReturn("1");

JavaDoc Links for: Mockito#mock and ThrowsExceptionClass

Alternatively, as is discussed in the Stubbing tutorial, order of the stubbing matters and last matching wins, so you might be able to also do:

Foo myMock = Mockito.mock(Foo.class);
Mockito.when(myMock.doSomething(Matchers.any(String.class))).thenThrow(IllegalArgumentException.class);
Mockito.when(myMock.doSomething(Matchers.eq("1"))).thenReturn("1");

I think what you are trying to test is aspect weaving and pointcut matching. Please note that that would be an integration rather than a unit test. If you really want to unit test your aspect logic and because you have tagged the question by "mockito" anyway, I suggest you do just that: Write a unit test and mock the aspect's joinpoint and maybe its other parameters, if any. Here is a slightly more complex example with some intra-aspect logic:

Java class to be targeted by aspect:

package de.scrum_master.app;

public class Application {
    public static void main(String[] args) {
        new Application().doSomething(11);
        new Application().doSomething(-22);
        new Application().doSomething(333);
    }

    public void doSomething(int number) {
        System.out.println("Doing something with number " + number);
    }
}

Aspect under test:

package de.scrum_master.aspect;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;

@Aspect
public class SampleAspect {
    @Around("execution(* doSomething(int)) && args(number)")
    public Object intercept(final ProceedingJoinPoint thisJoinPoint, int number) throws Throwable {
        System.out.println(thisJoinPoint + " -> " + number);
        if (number < 0)
            return thisJoinPoint.proceed(new Object[] { -number });
        if (number > 99)
            throw new RuntimeException("oops");
        return thisJoinPoint.proceed();
    }
}

Console log when running Application.main(..):

As you can see, the aspect passes on 11, negates -22 and throws an exception for 333:

execution(void de.scrum_master.app.Application.doSomething(int)) -> 11
Doing something with number 11
execution(void de.scrum_master.app.Application.doSomething(int)) -> -22
Doing something with number 22
execution(void de.scrum_master.app.Application.doSomething(int)) -> 333
Exception in thread "main" java.lang.RuntimeException: oops
    at de.scrum_master.aspect.SampleAspect.intercept(SampleAspect.aj:15)
    at de.scrum_master.app.Application.doSomething(Application.java:10)
    at de.scrum_master.app.Application.main(Application.java:7)

Unit test for aspect:

Now we really want to verify that the aspect does what it should and cover all execution paths:

package de.scrum_master.aspect;

import org.aspectj.lang.ProceedingJoinPoint;
import org.junit.Rule;
import org.junit.Test;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnit;
import org.mockito.junit.MockitoRule;

import static org.mockito.Mockito.*;

public class SampleAspectTest {
    @Rule
    public MockitoRule mockitoRule = MockitoJUnit.rule();

    @Mock
    private ProceedingJoinPoint proceedingJoinPoint;

    private SampleAspect sampleAspect = new SampleAspect();

    @Test
    public void testPositiveSmallNumber() throws Throwable {
        sampleAspect.intercept(proceedingJoinPoint, 11);
        // 'proceed()' is called exactly once
        verify(proceedingJoinPoint, times(1)).proceed();
        // 'proceed(Object[])' is never called
        verify(proceedingJoinPoint, never()).proceed(null);
    }

    @Test
    public void testNegativeNumber() throws Throwable {
        sampleAspect.intercept(proceedingJoinPoint, -22);
        // 'proceed()' is never called
        verify(proceedingJoinPoint, never()).proceed();
        // 'proceed(Object[])' is called exactly once
        verify(proceedingJoinPoint, times(1)).proceed(new Object[] { 22 });
    }

    @Test(expected = RuntimeException.class)
    public void testPositiveLargeNumber() throws Throwable {
        sampleAspect.intercept(proceedingJoinPoint, 333);
    }
}

Now run this simple JUnit + Mockito test in order to test the aspect logic in isolation, not the wiring/weaving logic. For the latter you would need another type of test.

P.S.: Only for you I used JUnit and Mockito. Usually I just use Spock and its built-in mocking capabilities. ;-)

I can only assume that you are looking for thenAnswer & Answer. With thenAnswer you can modify the arguments of the mocked method and also return a result from that method.

E.g:

Set<String> result = new HashSet<>();
result.add("123");

Mockito.when(mockedMtnService.getModelSearchStrings(Mockito.anyMap(), Mockito.anyObject())).thenAnswer(new Answer<Set>() {
    @Override
    public String answer(InvocationOnMock invocation) throws Throwable {
        Map<String,List<Object>> mapArg = (Map<String,List<Object>>)invocation.getArguments()[0];
        // do something with mapArg....
        return result;
    }
});

Or with Java 8 lambda:

Mockito.when(mockedMtnService.getModelSearchStrings(Mockito.anyMap(), Mockito.anyObject())).thenAnswer(invocation -> {
    Map<String,List<Object>> mapArg = (Map<String,List<Object>>)invocation.getArguments()[0];
    // do something with mapArg....
    return result;
});

If you want to stub out what INSTANCE returns, you can do it but it's kind of nasty (using reflection & bytecode manipulation). I created & tested a simple project with three classes using the PowerMock 1.4.12 / Mockito 1.9.0. All classes were in the same package.

SingletonObject.java

public enum SingletonObject {
    INSTANCE;
    private int num;

    protected void setNum(int num) {
        this.num = num;
    }

    public int getNum() {
        return num;
    }
}

SingletonConsumer.java

public class SingletonConsumer {
    public String consumeSingletonObject() {
        return String.valueOf(SingletonObject.INSTANCE.getNum());
    }
}

SingletonConsumerTest.java

import static org.junit.Assert.*;
import static org.powermock.api.mockito.PowerMockito.*;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;
import org.powermock.reflect.Whitebox;

@RunWith(PowerMockRunner.class)
@PrepareForTest({SingletonObject.class})
public class SingletonConsumerTest {
    @Test
    public void testConsumeSingletonObject() throws Exception {
        SingletonObject mockInstance = mock(SingletonObject.class);
        Whitebox.setInternalState(SingletonObject.class, "INSTANCE", mockInstance);

        when(mockInstance.getNum()).thenReturn(42);

        assertEquals("42", new SingletonConsumer().consumeSingletonObject());
    }
}

The call to the Whitebox.setInternalState replaces INSTANCE with a mock object that you can manipulate within your test.

Mockito.mock(Foo.class) results a object in type of Foo, but not exactly Foo class. As at the background it will create an anonymous proxy, which is a subclass of Foo. So, the class isn't the same.

One note to your implementation of isValid is that: do you really want to check the class, or just to check the type (that will also accept subclass, isAssignableFrom) of the class. If you check for type matching, then you can test your method with mocked class.

Also, do you think that you can somehow work on objects rather than classes (e.g. isValid(object))? Using object is a better approach in OOP than clazz in my perspective. I would suggest:

    public boolean isValid(Object obj) {
        return SOME_SET.stream().anyMatch(clazz -> clazz.isInstance(obj));
    }