How to use MockitoNotExtensible class of org.mockito.errorprone.bugpatterns package

Is it poorly designed and implemented code to have a method that internally calls other methods?

Not really. But I'd say that, in this situation, the method that calls the others should be tested as if the others where not already tested separately. That is, it protects you from situations where your public methods stops calling the other ones without you noticing it.

Yes, it makes for (sometimes) a lot of test code. I believe that this is the point: the pain in writing the tests is a good clue that you might want to consider extracting those sub-methods into a separate class.

If I can live with those tests, then I consider that the sub-methods are not to be extracted yet.

What is the best practice and/or approach in writing a unit test for such a method (assuming it is itself a good idea) if one has chosen Mockito as their mocking framework?

I'd do something like that:

public class Blah {
    public int publicMethod() {
        return innerMethod();
    }

    int innerMethod() {
        return 0;
    }
}


public class BlahTest {
    @Test
    public void blah() throws Exception {
        Blah spy = spy(new Blah());
        doReturn(1).when(spy).innerMethod();

        assertThat(spy.publicMethod()).isEqualTo(1);
    }
}

I suppose that "any" is actually a Mockito.any() method? In that case you can rather use Mockito.matches("regex"). See docs: https://static.javadoc.io/org.mockito/mockito-core/1.9.5/org/mockito/Matchers.html#matches(java.lang.String)

EDIT: It turns out that MockRestServiceServer uses Hamcrest matchers to verify the expectations (methods like requestTo, withSuccess etc.).

There is also a method matchesPattern(java.util.regex.Pattern pattern) in org/hamcrest/Matchers class which is available since Hamcrest 2, and it can be used to solve your problem.

But in your project you probably have the dependency on the older version of Hamcrest (1.3) which is used by, for example, junit 4.12, the latest spring-boot-starter-test-2.13, or, finally, org.mock-server.mockserver-netty.3.10.8 (transitively).

So, you need to:

1. Check the actual version of Hamcrest in your project and (if it's not 2+) update this dependency manually: https://mvnrepository.com/artifact/org.hamcrest/hamcrest/2.1

<dependency>
    <groupId>org.hamcrest</groupId>
    <artifactId>hamcrest</artifactId>
    <version>2.1</version>
    <scope>test</scope>
</dependency>

2. Update your test:

mockServer.expect(requestTo(matchesPattern(".*exact-example-url.com.*")))
    .andExpect(method(HttpMethod.GET))
    .andRespond(withSuccess("response", MediaType.APPLICATION_JSON));

I got this to work by doing this in the test:

CompletableFuture<Long> future = new CompletableFuture<>();
future.completeExceptionally(new Exception("HTTP call failed!"));

Mockito.when(mockClient.getSize())
        .thenReturn(future);

Not sure if this is the best way though.

Use the doReturn-when alternate stubbing syntax.

System under test:

public class MyClass {
  Set<? extends Number> getSet() {
    return new HashSet<Integer>();
  }
}

and the test case:

import static org.mockito.Mockito.*;

import java.util.HashSet;
import java.util.Set;

import org.junit.Test;

public class TestMyClass {
  @Test
  public void testGetSet() {
    final MyClass mockInstance = mock(MyClass.class);

    final Set<Integer> resultSet = new HashSet<Integer>();
    resultSet.add(1);
    resultSet.add(2);
    resultSet.add(3);

    doReturn(resultSet).when(mockInstance).getSet();

    System.out.println(mockInstance.getSet());
  }
}

No errors or warning suppression needed

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.

Fundamentally, you're trying to replace a private field with an alternative implementation, which means you'd violate encapsulation. Your only other option is to restructure the class or method, to make it better-designed for testing.

There are a lot of short answers in the comments, so I'm aggregating them here (and adding a couple of my own) as Community Wiki. If you have any alternatives, please feel free to add them here.

Restructure the class

• Create a setter for the field in question, or relax the field's visibility.

• Create a dependency-injecting override or static method that takes a DAO, and make the public instance method delegate to it. Test the more-flexible method instead.

  public String myMethod() { return myMethod(dao); }
  String myMethod(Dao dao) { /* real implementation here */ }
  

• Add a constructor overload or static factory method that replaces private fields for the sake of testing.

• Fully structure the class for dependency injection. (Sotirios Delimanolis, EJK)

Note that some of these can be package-private for testing, if you put your tests in the same Java package (possibly in a separate source tree). In all cases, good names and documentation are helpful to make your intentions clear.

Violate encapsulation

• Use reflection to set private fields in the class. (kinbiko - see answer)
• Use PowerMockito to replace the Dao constructor with a mock of your choice. (Dave Newton)

I think the PowerMockito version is not the problem. I tested the following code with versions

• 1.7.3,
• 2.0.0-beta.5 (your version),
• 2.0.2.

Application classes:

package de.scrum_master.stackoverflow.q52952222;

public class Tester {
  public static String sendFaqRequest(String one, String two) {
    return "real response";
  }
}

package de.scrum_master.stackoverflow.q52952222;

public class OtherClass {
  public static void methodThatCallsTesterStaticMethod(String one, String two, String three, boolean four, String five) {
    System.out.println(Tester.sendFaqRequest("A", "B"));
    System.out.println(Tester.sendFaqRequest("C", "D"));
    System.out.println(Tester.sendFaqRequest("E", "F"));
  }
}

Test classes:

package de.scrum_master.stackoverflow.q52952222;

import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;

import java.util.Arrays;

public class FirstResponseWithText implements Answer {
  @Override
  public Object answer(InvocationOnMock invocation) throws Throwable {
    Object[] args = invocation.getArguments();
    String methodName = invocation.getMethod().getName();
    return methodName + " called with arguments: " + Arrays.toString(args);
  }
}

package de.scrum_master.stackoverflow.q52952222;

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

import static org.mockito.Mockito.anyString;
import static org.mockito.Mockito.times;
import static org.powermock.api.mockito.PowerMockito.*;

@RunWith(PowerMockRunner.class)
@PrepareForTest({ Tester.class })
public class MyTest {
  @Test
  public void myTest() {
    // Tell PowerMockito that we want to mock static methods in this class
    mockStatic(Tester.class);
    // Stub return value for static method call
    when(Tester.sendFaqRequest(anyString(), anyString())).thenAnswer(new FirstResponseWithText());
    // Call method which calls our static method 3x
    OtherClass.methodThatCallsTesterStaticMethod("", "", "", false, "");
    // Verify that Tester.sendFaqRequest was called 3x
    verifyStatic(Tester.class, times(3));
    Tester.sendFaqRequest(anyString(), anyString());
  }
}

So if this does not work for you and your Maven or Gradle dependencies are also okay, the difference is maybe in your FirstResponseWithText class. Maybe you want to show it so we can all see what kind of magic you do in there. As you can see from my sample code, I had to make several educated guesses because you only share a little snippet of test code and not MCVE like you should. This way I can only speculate and actually I do not like to because it might be a waste of time for both you and myself.

It's a defect in Mockito with loading plugins when context class loader is different from which is used to load PowerMock and Mockito.

It could be fixed in Mockito 2, but as it mentioned in comments

Not sure we have the build infrastructure to backport the fix on 1.x

For Mockito 1, fix cannot be delivered, so I fixed in in PowerMock and fix will be include in next PowerMock release (PowerMock 1.6.5).

Dependency Injection

If you inject the Bar instance, or a factory that is used for creating the Bar instance (or one of the other 483 ways of doing this), you'd have the access necessary to do perform the test.

Factory Example:

Given a Foo class written like this:

public class Foo {
  private BarFactory barFactory;

  public Foo(BarFactory factory) {
    this.barFactory = factory;
  }

  public void foo() {
    Bar bar = this.barFactory.createBar();
    bar.someMethod();
  }
}

in your test method you can inject a BarFactory like this:

@Test
public void testDoFoo() {
  Bar bar = mock(Bar.class);
  BarFactory myFactory = new BarFactory() {
    public Bar createBar() { return bar;}
  };
  
  Foo foo = new Foo(myFactory);
  foo.foo();

  verify(bar, times(1)).someMethod();
}

Bonus: This is an example of how TDD(Test Driven Development) can drive the design of your code.