How to use methodNameContains method of org.mockitousage.junitrunner.Filters class

A unit test shouldn't use any Spring configuration. You should simply instantiate your component, and inject dependencies (usually fake ones) manually.

You used field injection, which makes it a bit harder. With constructor injection, all you would need to do is

Logger logger = LoggerFactory.getLogger(MyController.class);
MyController controller = new MyController(logger);

Mockito can help injecting fake dependencies for you, though, even when using field injection, thanks to the @Mock, @Spy and @InjectMocks annotations:

@Spy
private Logger logger = LoggerFactory.getLogger(MyController.class);

@InjectMocks
private MyController controller;

@Before
public void prepare() {
    MockitoAnnotations.initMocks(this);
}

That said, if I'm not mistaken, you're not using @RunWith(SpringJUnit4ClassRunner.class), so your test runner doesn't know anything about Spring, and thus doesn't create or use any Spring configuration.

For any other type you can use any(). This will match an argument of given type:

any(UUID.class)

You can find more information in the documentation.

New feature added to Mockito makes this even easier,

ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);
verify(mock).doSomething(argument.capture());
assertEquals("John", argument.getValue().getName());

Take a look at Mockito documentation

In case when there are more than one parameters, and capturing of only single param is desired, use other ArgumentMatchers to wrap the rest of the arguments:

verify(mock).doSomething(eq(someValue), eq(someOtherValue), argument.capture());
assertEquals("John", argument.getValue().getName());

If you really don't have a choice for refactoring you can mock/stub everything in the super method call e.g.

    class BaseService {

        public void validate(){
            fail(" I must not be called");
        }

        public void save(){
            //Save method of super will still be called.
            validate();
        }
    }

    class ChildService extends BaseService{

        public void load(){}

        public void save(){
            super.save();
            load();
        }
    }

    @Test
    public void testSave() {
        ChildService classToTest = Mockito.spy(new ChildService());

        // Prevent/stub logic in super.save()
        Mockito.doNothing().when((BaseService)classToTest).validate();

        // When
        classToTest.save();

        // Then
        verify(classToTest).load();
    }

Technically speaking both "mocks" and "spies" are a special kind of "test doubles".

Mockito is unfortunately making the distinction weird.

A mock in mockito is a normal mock in other mocking frameworks (allows you to stub invocations; that is, return specific values out of method calls).

A spy in mockito is a partial mock in other mocking frameworks (part of the object will be mocked and part will use real method invocations).

Try adding this annotation to your Test class:

@PowerMockIgnore("javax.management.*")

Worked for me.

This is a perfect example for making functions more testable. This function takes no input and produces no output, affecting the world only via side effect, making it completely untestable through standard means.

To refactor this function to make it more testable:

• Don't ask the user for input via scanner, take the user's input as an input parameter.
• Don't print the result, return it.

The caller of the function can then decide how to provide the inputs and what to do with the output. Your modified program can ask for user input, call the function, then print the output. A testing framework can supply the input from a list of inputs to test, and check the outputs against the expected values.

The two syntaxes for stubbing are roughly equivalent. However, you can always use doReturn/when for stubbing; but there are cases where you can't use when/thenReturn. Stubbing void methods is one such. Others include use with Mockito spies, and stubbing the same method more than once.

One thing that when/thenReturn gives you, that doReturn/when doesn't, is type-checking of the value that you're returning, at compile time. However, I believe this is of almost no value - if you've got the type wrong, you'll find out as soon as you run your test.

I strongly recommend only using doReturn/when. There is no point in learning two syntaxes when one will do.

You may wish to refer to my answer at Forming Mockito "grammars" - a more detailed answer to a very closely related question.

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
}