How to use testRaw method of org.mockito.internal.configuration.MockAnnotationProcessorTest class

Alright, I figured it out thanks to Stefan Birkner's reference

Here is the correction to my sample code:

import org.mockito.Mockito;
import org.powermock.api.mockito.PowerMockito;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;

import org.junit.Test;
import org.junit.runner.RunWith;

@RunWith(PowerMockRunner.class)
@PrepareForTest(Test1.class)
public class PowerMockTest {
    @Test
    public void staticVerifyTest() {
        PowerMockito.mockStatic(Test1.class);
        // Test
        Test1.staticMethod();
        PowerMockito.verifyStatic();
        Test1.staticMethod();
    }
}

After the static method is invoked, you need to verify that it was called by calling it again after your verifyStatic() call.

i.e.

        Test1.staticMethod();
        PowerMockito.verifyStatic();
        Test1.staticMethod();

You can also check if it was called multiple times like this...

Test1.staticMethod();
Test1.staticMethod();
Test1.staticMethod();
PowerMockito.verifyStatic(Mockito.times(3));
Test1.staticMethod();

Verification with timeout is intended to be used to verify whether or not the operation has been invoked concurrently within the specified timeout.

It provides a limited form of verification for concurrent operations.

The following examples demonstrate the behaviour:

private final Runnable asyncOperation = new Runnable() {
    @Override
    public void run() {
        try {
            Thread.sleep(1000);
            timeoutable.longOperation();
        } catch (InterruptedException e) {
        }
    }

};

@Test
public void testMockitoConcurrentTimeoutSucceeds(){
    new Thread(asyncOperation).start();
    verify(timeoutable, timeout(2000)).longOperation();
}

@Test
public void testMockitoConcurrentTimeoutFails(){
    new Thread(asyncOperation).start();
    verify(timeoutable, timeout(100)).longOperation();
}

Mocking static methods is available since Mockito 3.4.

See pull request: Mockito #1013: Defines and implements API for static mocking.

Please note that the fact that this feature is available is not equivalent with recommendation to use it. It is aimed at legacy apps where you cannot refactor the source code.

Having said that:

Test when static method takes no arguments:

try (MockedStatic<SomePublicClass> dummyStatic = Mockito.mockStatic(SomePublicClass.class)) {
    dummyStatic.when(SomePublicClass::myPublicStaticFunc)
               .thenReturn(5);
    // when
    System.out.println(SomePublicClass.myPublicStaticFunc());
    //then
    dummyStatic.verify(
            times(1),
            SomePublicClass::myPublicStaticFunc
    );
}

Test when static methods takes arguments:

try (MockedStatic<SomePublicClass> dummyStatic = Mockito.mockStatic(SomePublicClass.class)) {
    dummyStatic.when(() -> SomePublicClass.myPublicStaticFunc(anyInt()))
               .thenReturn(5);
    // when
    System.out.println(SomePublicClass.myPublicStaticFunc(7));
    //then
    dummyStatic.verify(
            times(1), 
            () -> SomePublicClass.myPublicStaticFunc(anyInt())
    );
}

Plain Mockito library

import org.mockito.Mock;
...
@Mock
MyService myservice;

and

import org.mockito.Mockito;
...
MyService myservice = Mockito.mock(MyService.class);

come from the Mockito library and are functionally equivalent.
They allow to mock a class or an interface and to record and verify behaviors on it.

The way using annotation is shorter, so preferable and often preferred.

---

Note that to enable Mockito annotations during test executions, the MockitoAnnotations.initMocks(this) static method has to be called.
To avoid side effect between tests, it is advised to do it before each test execution :

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

Another way to enable Mockito annotations is annotating the test class with @RunWith by specifying the MockitoJUnitRunner that does this task and also other useful things :

@RunWith(org.mockito.runners.MockitoJUnitRunner.class)
public MyClassTest{...}

---

Spring Boot library wrapping Mockito library

This is indeed a Spring Boot class:

import org.springframework.boot.test.mock.mockito.MockBean;
...
@MockBean
MyService myservice;

The class is included in the spring-boot-test library.

It allows to add Mockito mocks in a Spring ApplicationContext.
If a bean, compatible with the declared class exists in the context, it replaces it by the mock.
If it is not the case, it adds the mock in the context as a bean.

Javadoc reference :

Annotation that can be used to add mocks to a Spring ApplicationContext.

...

If any existing single bean of the same type defined in the context will be replaced by the mock, if no existing bean is defined a new one will be added.

---

When use classic/plain Mockito and when use @MockBean from Spring Boot ?

Unit tests are designed to test a component in isolation from other components and unit tests have also a requirement : being as fast as possible in terms of execution time as these tests may be executed each day dozen times on the developer machines.

Consequently, here is a simple guideline :

As you write a test that doesn't need any dependencies from the Spring Boot container, the classic/plain Mockito is the way to follow : it is fast and favors the isolation of the tested component.
If your test needs to rely on the Spring Boot container and you want also to add or mock one of the container beans : @MockBean from Spring Boot is the way.

---

Typical usage of Spring Boot @MockBean

As we write a test class annotated with @WebMvcTest (web test slice).

The Spring Boot documentation summarizes that very well :

Often @WebMvcTest will be limited to a single controller and used in combination with @MockBean to provide mock implementations for required collaborators.

Here is an example :

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mockito;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.boot.test.mock.mockito.MockBean;
import org.springframework.http.MediaType;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.test.web.servlet.MockMvc;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;

@RunWith(SpringRunner.class)
@WebMvcTest(FooController.class)
public class FooControllerTest {

    @Autowired
    private MockMvc mvc;

    @MockBean
    private FooService fooServiceMock;

    @Test
    public void testExample() throws Exception {
         Foo mockedFoo = new Foo("one", "two");

         Mockito.when(fooServiceMock.get(1))
                .thenReturn(mockedFoo);

         mvc.perform(get("foos/1")
            .accept(MediaType.TEXT_PLAIN))
            .andExpect(status().isOk())
            .andExpect(content().string("one two"));
    }

}

I've found that Mockito and Powermock are a good combination for this. Actually there's a blog post with a sample, where the File-class's constructor is mocked for testing purposes. Here's also a small example I threw together:

public class ClassToTest
{
    public void openFile(String fileName)
    {
        File f = new File(fileName);
        if(!f.exists())
        {
            throw new RuntimeException("File not found!");
        }
    }
}

Testing with Mockito + Powermock:

@RunWith(PowerMockRunner.class)
@PrepareForTest(ClassToTest.class)
public class FileTest
{
    @Test
    public void testFile() throws Exception
    {
        //Set up a mocked File-object
        File mockedFile = Mockito.mock(File.class);
        Mockito.when(mockedFile.exists()).thenReturn(true);

        //Trap constructor calls to return the mocked File-object
        PowerMockito.whenNew(File.class).withParameterTypes(String.class).withArguments(Matchers.anyString()).thenReturn(mockedFile);

        //Do the test
        ClassToTest classToTest = new ClassToTest();
        classToTest.openFile("testfile.txt");

        //Verify that the File was created and the exists-method of the mock was called
        PowerMockito.verifyNew(File.class).withArguments("testfile.txt");
        Mockito.verify(mockedFile).exists();
    }
}

This org.junit.Test is a JUnit 4 annotation. A Junit5 test runner will not discover a test annotated with org.junit.Test.

A Junit5 test runner will discover a test annotated with org.junit.jupiter.api.Test.

So, this explains why you get "No Test found with Test Runner JUnit 5" when attempting to run a test context which does not contain any tests annotated with org.junit.jupiter.api.Test.

It sounds like you might be migrating from Junit4 to Junit5. If so, there are several changes you'll need to come to terms with. The Junit5 docs offer some useful tips including:

Annotations reside in the org.junit.jupiter.api package.

Assertions reside in org.junit.jupiter.api.Assertions.

Assumptions reside in org.junit.jupiter.api.Assumptions.

@Before and @After no longer exist; use @BeforeEach and @AfterEach instead.

@BeforeClass and @AfterClass no longer exist; use @BeforeAll and @AfterAll instead.

@Ignore no longer exists: use @Disabled or one of the other built-in execution conditions instead

@Category no longer exists; use @Tag instead.

@RunWith no longer exists; superseded by @ExtendWith.

@Rule and @ClassRule no longer exist; superseded by @ExtendWith and @RegisterExtension

To make this work, you need to use Powermockito to intercept the constructor calls (new InputStreamReader(...), new BufferedReader(...)) so that your mocks get returned. An example is below. In your case, just intercepting the new BufferedReader call may be enough.

Assume the following is the code you want to test:

package test;

import java.io.*;

public class SUT {

    public String doSomething() throws IOException {
        InputStreamReader reader =
                new InputStreamReader(getFileAsStream(null, null));
        BufferedReader bReader =
                new BufferedReader(reader);

        return bReader.readLine();
    }

    private InputStream getFileAsStream(Object resourceResolver, Object iconPath)
            throws FileNotFoundException {
        return new ByteArrayInputStream("".getBytes());
    }
}

The following test code is an example of how to intercept the constructor calls:

package test;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.api.mockito.PowerMockito;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;

import java.io.BufferedReader;
import java.io.InputStreamReader;

import static org.junit.Assert.assertEquals;
import static org.powermock.api.mockito.PowerMockito.doReturn;
import static org.powermock.api.mockito.PowerMockito.mock;

@RunWith(PowerMockRunner.class)
@PrepareForTest({ SUT.class })
public class SUTTest {

    @Test
    public void doSomethingReturnsValueFromBufferedReader() throws Exception {
        // Arrange
        SUT sut = new SUT();
        InputStreamReader inputStreamReaderMock = mock(InputStreamReader.class);
        BufferedReader bufferedReaderMock = mock(BufferedReader.class);

        // Set your mocks up to be returned when the new ...Reader calls 
        // are executed in sut.doSomething()
        PowerMockito.whenNew(InputStreamReader.class).
                     withAnyArguments().thenReturn(inputStreamReaderMock);
        PowerMockito.whenNew(BufferedReader.class).
                     withArguments(inputStreamReaderMock).
                     thenReturn(bufferedReaderMock);

        // Set the value you want bReader.readLine() to return 
        // when sut.doSomething() executes
        final String bufferedReaderReturnValue = "myValue";
        doReturn(bufferedReaderReturnValue).when(bufferedReaderMock).readLine();

        // Act
        String result = sut.doSomething();

        // Assert
        assertEquals(bufferedReaderReturnValue, result);
    }
}

This hopefully helps you in your immediate problem. However, it seems to me that what you're creating will be a very slow, confusing and brittle test. Right now, you're mocking so much that it makes very hard to determine what you're actually trying to test.

The high amount of mocking probably indicates that the design of the code you're testing would need some work to improve testability. If you can't touch the code, then you can't - but try to make your test more readable and intuitive ("When this method is invoked, this thing should happen, because...").

Mockito comes with a helper class to save you some reflection boiler plate code:

import org.mockito.internal.util.reflection.Whitebox;

//...

@Mock
private Person mockedPerson;
private Test underTest;

// ...

@Test
public void testMethod() {
    Whitebox.setInternalState(underTest, "person", mockedPerson);
    // ...
}

Update: Unfortunately the mockito team decided to remove the class in Mockito 2. So you are back to writing your own reflection boilerplate code, use another library (e.g. Apache Commons Lang), or simply pilfer the Whitebox class (it is MIT licensed).

Update 2: JUnit 5 comes with its own ReflectionSupport and AnnotationSupport classes that might be useful and save you from pulling in yet another library.

You would need a spy, not a mock A:

    A a = Mockito.spy(new A(1,1));
    a.getPrice(2);
    verify(a, times(1)).getPriceForOne();