How to use should_fail_invalid_checked_exception method of org.mockito.internal.stubbing.answers.ThrowsExceptionTest class

It's counting your setup as invocations since deeps stubs is not supported in the verification API, and complains on the second call which is:

when(mockSandBox.getSand().doB()).thenReturn(1);

I would skip using RETURNS_DEEP_STUBS and just use another mock:

...
@Mock
SandBox mockSandBox;

@Mock
Sand sand;

@Test
public void should(){
    when(mockSandBox.getSand()).thenReturn(sand);
    when(sand.doA()).thenReturn(1);
    when(sand.doB()).thenReturn(1);
    when(sand.doC()).thenReturn(1);
...

According to the Mockito documentation you can set different behavior for consecutive method calls.

when(mock.someMethod("some arg"))
    .thenThrow(new RuntimeException())
    .thenReturn("foo");

In case of a void method you can do something similar (Mockito documentation)

doThrow(new RuntimeException())
    .doNothing()
    .when(mock).doSomething();

I could make your unit test pass by modifying 2 things in your code:

1. Mock mockServerSocket.accept() properly

Up to now, you mock mockServerSocket.accept() too early because mockTestClientSocket has not yet been set so it will return null, you need to set it first so your code should rather be:

mockServerSocket = mock(ServerSocket.class);
// Set it first
mockTestClientSocket = mock(Socket.class);

try {
    // Then mock it
    when(mockServerSocket.accept()).thenReturn(mockTestClientSocket);
} catch (IOException e) {
    fail(e.getMessage());
}
...

2. Synchronize your threads properly

As you launch a dedicated thread to manage your client socket, you need to synchronize your threads in order to make sure that your message will be ready to be read.

To do this you could:

1. Simplify your code by calling reader.readLine() but it is a blocking approach since your current thread will wait as long as it is needed for the other thread to write the line (the message here).

The code could be:

BufferedReader reader = ...

String receivedMessage = reader.readLine();
assertEquals("Hello, world!", receivedMessage);
mockTestClientSocket.close();
connection.closeSocket();

2. Set a value for TIMEOUT_TIME big enough even exaggeratedly big to make sure that the other thread will be ready, so for example as it is a value in nanoseconds, you could set it to 30 seconds so to 30_000_000_000L. If you don't set a value big enough, your test could be unstable in slow and/or overloaded and/or shared system such as server used for continuous integration.

@Mock creates a mock. @InjectMocks creates an instance of the class and injects the mocks that are created with the @Mock (or @Spy) annotations into this instance.

Note you must use @RunWith(MockitoJUnitRunner.class) or Mockito.initMocks(this) to initialize these mocks and inject them (JUnit 4).

With JUnit 5, you must use @ExtendWith(MockitoExtension.class).

@RunWith(MockitoJUnitRunner.class) // JUnit 4
// @ExtendWith(MockitoExtension.class) for JUnit 5
public class SomeManagerTest {

    @InjectMocks
    private SomeManager someManager;

    @Mock
    private SomeDependency someDependency; // this will be injected into someManager
 
     // tests...

}

When calling with mocks org.elasticsearch.Build#getElasticsearchCodebase

Build.class.getProtectionDomain().getCodeSource().getLocation()

returns null because the code has no location (Dynamic method generated by cglib.)

So when initializing org.elasticsearch.Build during your mock code using

final URL url = getElasticsearchCodebase(); // url is null
final String urlStr = url.toString(); // null pointer exception.

Of course, the mock will not success and throw ExceptionInInitializerError which indicates an exception occurred during evaluation of a static initializer or the initializer for a static variable.

You can easily reproduce this exception using following code:

@RunWith(PowerMockRunner.class)
@PrepareForTest({QueryBuilders.class})
public class MyQueryBuilderTest {

    @Test
    public void test() {
        final Build current = Build.CURRENT;
    }

}

The mocks that Mockito creates are generated class files; however, Mockito is designed for use in a JVM, so out of the box it generates .class files using cglib. Android Instrumentation test cases run on devices or emulators, so they need Dalvik .dex files.

You'll need to ensure you're including DexMaker on your classpath. The dexmaker-mockito Maven project seems to be right, though it depends on Mockito 1.10.5, which is a few versions behind at this point.

As a side note, unless you use the Android Testing Support Library, you will need to use JUnit3 semantics. You will not be able to use @Rule fields or custom test runners; you will also need to override setUp and tearDown (as opposed to @Before and @After annotations) and name your tests as testFooBar (as opposed to @Test annotations).

After a lot of trial and error I managed to solve this problem.

I dropped the

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = ProductCompositeServiceApplication.class)

annotations aboved the test class.

I marked the class that I was testing with @InjectMocks and the dependencies with @Mock:

public class ProductCompositeIntegrationTest {
    @InjectMocks
    private ProductCompositeIntegration productIntegration;

    @Mock
    private ServiceUtils util;

    private MockRestServiceServer mockServer;

    private RestTemplate restTemplate = new RestTemplate();

    @Before
    public void init() {
        MockitoAnnotations.initMocks(this);
        mockServer = MockRestServiceServer.createServer(restTemplate);
        productIntegration.setRestTemplate(restTemplate);
    }

    @Test
    public void someTests() {
        when(util.getServiceUrl("product")).thenReturn(URI.create("http://localhost:8080/test"));
        //Test code...
    }
}

I'm not sure if this is the best approach ("the Spring way"), but this worked for me.

This article made it all clear to me: http://rdafbn.blogspot.be/2014/01/testing-spring-components-with-mockito.html

org.mockito.runners.MockitoJUnitRunner is now indeed deprecated, you are supposed to use org.mockito.junit.MockitoJUnitRunner instead. As you can see only the package name has changed, the simple name of the class is still MockitoJUnitRunner.

Excerpt from the javadoc of org.mockito.runners.MockitoJUnitRunner:

Moved to MockitoJUnitRunner, this class will be removed with Mockito 3

You can try the following idea (taken from similar discussion on github):

.doAnswer { throw ServiceException("Bad Request") }