Try the anyVararg() matcher. This was introduced in 1.8.1.

The problem with using RETURN_DEEP_STUBS is that you'll get a different mock each time you call a method. I think from your question that you want to use a default Answer that actually returns the mock on which it was called, for each method that has the right return type. This could look something like the following. Note that I haven't tested this, so it may contain typos, but I hope that the intention is clear in any case.

import static org.mockito.Mockito.RETURNS_DEFAULTS;
import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;

public class SelfReturningAnswer implements Answer<Object> {

    public Object answer(InvocationOnMock invocation) throws Throwable {
        Object mock = invocation.getMock();
        if(invocation.getMethod().getReturnType().isInstance(mock)){
            return mock;
        }
        return RETURNS_DEFAULTS.answer(invocation);
    }
}

Then, when you create your mock, specify this as your default answer. This will make your mock return itself from each method that it can; but it will behave like an ordinary mock when you call a method whose return type is wrong for the mock.

Create your mock like this

Builder mockBuilder = mock( Builder.class, new SelfReturningAnswer());

or create a constant for this class and write something like

@Mock(answer = SELF_RETURNING) private Builder mockBuilder;

Hope that helps.

OK, I think this is very specific to TestNG configurations, since all of the JUnit examples work 'out of the box'!

Read through this link from the PowerMock GitHub site which describes further detail on how to use TestNG together with PowerMock. Exactly your scenario of verifying calls to mocked static methods is described there using this example code:

@PrepareForTest(IdGenerator.class)
public class MyTestClass {

   @Test
   public void demoStaticMethodMocking() throws Exception {
      mockStatic(IdGenerator.class);
      when(IdGenerator.generateNewId()).thenReturn(2L);       
      new ClassUnderTest().methodToTest();

      // Optionally verify that the static method was actually called
      verifyStatic();
      IdGenerator.generateNewId();
   }

}

Which is then followed by this nugget of information:

For this to work you need to tell TestNG to use the PowerMock object factory

This is done using either TestNG XML config, or in the test's code itself. For completeness I've copied below the options given at the above URL. FWIW I extended PowerMockTestCase and the verification worked as you expect.

Finally, don't forget to @PrepareForTest the correct class - i.e. the class containing the static methods which you want to mock, as @Bax pointed out here.

As a further hint (which you probably already know about, but worth mentioning here anyway) since you aren't using Mockito to mock objects, MockitoAnnotations.initMocks(this) can be safely deleted.

Once you've got all this working, you might also like to consider whether the use of 'Black Magic' tools like Powermock is actually exposing code smells in your design? Especially since it looks like the classes containing static methods are under your ownership. This means you could use an alternative design that doesn't use statics. I highly recommend Michael Feathers' book Working Effectively with Legacy Code, it might just change your whole approach to software design and testing...

Good luck!

Configure TestNG to use the PowerMock object factory

Using suite.xml

In your suite.xml add the following in the suite tag: object-factory="org.powermock.modules.testng.PowerMockObjectFactory" e.g.

<suite name="dgf" verbose="10"
    object-factory="org.powermock.modules.testng.PowerMockObjectFactory">
    <test name="dgf">
        <classes>
            <class name="com.mycompany.Test1"/>
            <class name="com.mycompany.Test2"/>
        </classes>
    </test> 

If you're using Maven you may need to point out the file to Surefire:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <suiteXmlFiles>
        <suiteXmlFile>suite.xml</suiteXmlFile>
        </suiteXmlFiles>
    </configuration> 
</plugin> 

Programmatically

Add a method like this to your test class:

@ObjectFactory public IObjectFactory getObjectFactory() {
     return new org.powermock.modules.testng.PowerMockObjectFactory(); 
} 

or to be on the safe side you can also extend from the PowerMockTestCase:

@PrepareForTest(IdGenerator.class) 
public class MyTestClass extends PowerMockTestCase { ... }

Use some mocking framework e.g. Mockito or JMock which comes with mocking capacity of such objects.

In Mockito, you can do mocking as:

 HttpServletRequest  mockedRequest = Mockito.mock(HttpServletRequest.class);

For details on Mockito, see: How do I drink it? on the Mockito site.

In JMock, you can do mocking as :

 Mockery context = new Mockery();
 HttpServletRequest  mockedRequest = context.mock(HttpServletRequest.class);

For details on jMock, please refer: jMock - Getting Started

Yes, spy() is fit for your purpose. The warning is due to the fact that real methods are invoked, and hence you can get unexpected results (for example - real money being withdrawn from a bank account)

When you want to use the @Mock annotation you should use the MockitoJUnitRunner

@RunWith(MockitoJUnitRunner.class)
public class MockitoTest {

    @Mock
    private IRoutingObjHttpClient routingClientMock;

    @Test
    public void testSendRoutingRequest() throws Exception {
        // ...
    }

}

See also this tutorial.

In the end, this is all about wording.

When you think of "correct" in its very fundamental sense, as in correctness, then the answer is simply: no.

You see, the goal of an integration test is to ensure that your integrated system (consisting of multiple, different components) functions as expected. The purpose of an integration test is to verify that your "plumbing" of components works as expected. Therefore: you can't verify that your system works when parts of that system are mocked out.

But then, you can think "correctness" less strictly.

Example: companies selling cars have to test ECUs. Basically a piece of hardware, running a potentially huge software stack. These ECUs normally operate within cars. So when you want to integration test an ECU, you would have to put the ECU into a car for testing, right? A car that probably doesn't exist yet. The solution here: there are hardware emulators. You plug the ECU into that emulator, and the ECU "thinks" that sits inside a real car.

So: there are good arguments to claim "a true integration test can't use mocking", but at the same time, in the real world, such "mocking" happens all the time.

The real answer is therefore: it depends on context. Therefore there isn't a universal answer. Instead, this is about communication. You "simply" have to ensure that all people in your group/org have the same understanding of such terms.

The term itself can be interpreted in different ways. You (jointly!) pick that definition that best fits your needs, to then make sure all people contributing to your project share that view (or at least know about it).

This would be hard to test because it loops. One solution would be to break out this.client.newCall(request).execute() into a separate function sendRequest(Request request, int attemptsRemaining). Then you could use a spy that stubs that method to return different responses depending on the number of attempts remaining.
The nice thing I realized about okhttp is that you can just build a fake response yourself. For example,

Request mockRequest = new Request.Builder()
                .url("https://some-url.com")
                .build();
return new Response.Builder()
                .request(mockRequest)
                .protocol(Protocol.HTTP_2)
                .code(401) // status code
                .message("")
                .body(ResponseBody.create(
                        MediaType.get("application/json; charset=utf-8"),
                        "{}"
                ))
                .build();

So you can create and stub a simple method that returns a response, and you're basically good to go for testing.

Spring's MockRestServiceServer is exactly what you're looking for.

Short description from javadoc of the class:

Main entry point for client-side REST testing. Used for tests that involve direct or indirect (through client code) use of the RestTemplate. Provides a way to set up fine-grained expectations on the requests that will be performed through the RestTemplate and a way to define the responses to send back removing the need for an actual running server.

Try to set up your test like this:

@WebAppConfiguration
@ContextConfiguration(classes = {YourSpringConfig.class})
@RunWith(SpringJUnit4ClassRunner.class)
public class ExampleResourceTest {

    private MockMvc mockMvc;
    private MockRestServiceServer mockRestServiceServer;

    @Autowired
    private WebApplicationContext wac;

    @Autowired
    private RestOperations restOperations;

    @Before
    public void setUp() throws Exception {
        mockMvc = MockMvcBuilders.webAppContextSetup(this.wac).build();
        mockRestServiceServer = MockRestServiceServer.createServer((RestTemplate) restOperations);
    }


    @Test
    public void testMyApiCall() throws Exception {
        // Following line verifies that our code behind /api/my/endpoint made a REST PUT
        // with expected parameters to remote service successfully
        expectRestCallSuccess();

        this.mockMvc.perform(MockMvcRequestBuilders.get("/api/my/endpoint"))
            .andExpect(status().isOk());
    }

    private void expectRestCallSuccess() {
        mockRestServiceServer.expect(
            requestTo("http://remote.rest.service/api/resource"))
            .andExpect(method(PUT))
            .andRespond(withSuccess("{\"message\": \"hello\"}", APPLICATION_JSON));
    }


}