How to use should_print_if_method_has_not_been_stubbed method of org.mockito.internal.debugging.VerboseMockInvocationLoggerTest class

Update (9/07/2015):

You can continue to work with 22.2.1 if you use the following excludes:

androidTestCompile ('com.android.support.test.espresso:espresso-core:2.2') {
    exclude group: 'com.android.support', module: 'support-annotations'
}
androidTestCompile ('com.android.support.test:runner:0.3') {
    exclude group: 'com.android.support', module: 'support-annotations'
}
androidTestCompile ('com.android.support.test:rules:0.3') {
    exclude group: 'com.android.support', module: 'support-annotations'
}

If you depend on espresso-contrib, you need the exclude as well.

Update (8/03/2015):

With support library 22.2.1, the dependencies are broken again; please don't upgrade to 22.2.1 until a new runner is released.

Update (6/04/2015):

With the latest release of runner 0.3 and rules 0.3, this answer is no longer needed. You can simply use

androidTestCompile 'com.android.support.test:runner:0.3'
androidTestCompile 'com.android.support.test:rules:0.3'
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2'

with latest support libraries. (22.2.0 as of this writing)

Update (5/30/2015):

compile 'com.android.support:appcompat-v7:22.2.0'
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2'
// com.android.support.test:testing-support-lib:0.1 // <-- causes issue

Update (4/24/2015):

The problem is that com.android.support:support-v4:22.1.1 is clashing with com.android.support.test:runner:0.2 (as that depends on com.android.support:support-v4:22.0.0).

com.android.support.test.espresso:espresso-core:2.1 has a dependency on com.android.support.test:runner:0.2, so it also causes the same error.

So, this combination will work:

compile 'com.android.support:support-v4:22.0.0'
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.1'

...and so will this one (without 'com.android.support.test:runner:0.2'):

compile 'com.android.support:support-v4:22.1.0'
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.0'

Original Answer:

Contrary to what the Espresso documentation says, you should remove this dependency:

androidTestCompile 'com.android.support.test:runner:0.2'

As it is the cause for library version conflict.

You should also update to Android gradle plugin 1.1.1, as that version will tell you the exact version conflict, which is useful in this case.

There is a couple options:

1. Cast it
2. Use @Mock annotation

Examples:

Set<String> mySet = (Set<String>) mock(Set.class);

--or--

@Mock
private Set<String> mySet;

@Before
public void doBefore() throws Exception {
    MockitoAnnotations.initMocks(this.getClass()); //this should create mocks for your objects...
}

You may just do this:

Mockito.mock(Dog.class, Mockito.withSettings()
        .useConstructor(999)
        .defaultAnswer(Mockito.CALLS_REAL_METHODS)
);

Where 999 - is any integer for id argument. So you don't have to inherit your abstract class anymore. You also may pass as many arguments as constructor needed e.g.:

.useConstructor(new Object(), "my string", 5.5, null)

I think I am understanding your question. Let me re-phrase, you have a function that you are trying to test and want to mock the results of a function called within that function, but in a different class. I have handled that in the following way.

public MyUnitTest {
    private static final MyClass2 class2 = mock(MyClass2.class);

    @Begin
    public void setupTests() {
        when(class2.get(1000)).thenReturn(new User(1000, "John"));
        when(class2.validateObject(anyObj()).thenReturn(true);
    }

    @Test
    public void testFunctionCall() {
        String out = myClass.functionCall();
        assertThat(out).isEqualTo("Output");
    }
}

What this is doing is that within the function wrapped with the @Before annotation, I am setting up how I want the functions in class2 to respond given specific inputs. Then, from within the actual test, I am just calling the function that I am trying to test in the class I want to test. In this case, the myClass.functionCall() is running through as normal and you are not overwriting any of its methods, but you are just mocking the outputs that it gets from the methods (or method) within MyClass2.

The problem is, you cannot mix argument matchers and real arguments in a mocked call. So, rather do this:

when(serviceValidatorStub.validate(
    any(),
    isA(UserCommentRequestValidator.class),
    eq(UserCommentResponse.class),
    eq(UserCommentError.class))
).thenReturn(new UserCommentResponse());

Notice the use of the eq() argument matcher for matching equality.

see: https://static.javadoc.io/org.mockito/mockito-core/1.10.19/org/mockito/Matchers.html#eq(T)

Also, you could use the same() argument matcher for Class<?> types - this matches same identity, like the == Java operator.

Just incase any M1 Mac users stumble onto this page like I did.

My Issue -

My spring boot project with wiremock tests, would run on my old intel mac but failed to run when I moved to my new M1 Mac.

_ _

I had 2 error messages

• java.lang.IllegalStateException: No Server ALPNProcessors!
• Suppressed: java.lang.UnsatisfiedLinkError: no conscrypt_openjdk_jni-osx-aarch_64

Fix -

I needed a property to test.application

wiremock.server.httpsPort=-1

ExpectedException works by wrapping your entire test method in a try-catch block via a JUnit @Rule. When your code throws an exception, it goes up the stack to the nearest try/catch, which happens to be in the ExpectedException instance (which checks that it is the exception you're expecting).

In Java, if an uncaught exception occurs in a method, control will never return to statements later in that method. The same rules apply here: Control never returns to the statements in your test after the exception.

Technically, you could put the verifications in a finally block, but that tends to be a bad habit. EDIT: Your system-under-test might throw an unexpected exception, or no exception at all, which would give you a helpful failure message and trace; however, if that failure then causes your verifications or assertions to fail in the finally block, then Java will show that rather than a message about the unexpected exception or unexpected success. This can make debugging difficult, especially because your error will come from lines of code following the root cause of the error, incorrectly implying that the code above it succeeded.

If you really need to verify state after the exception, on a per-method basis, you can always revert back to this idiom:

@Test
public void testExpectedException()
{
  MockedObject mockObj = mock(MockedObj.class);
  MySubject subject = new MySubject(mockedObj);
  try {
    subject.someMethodThrowingException();
    fail("Expected MyException.");
  } catch (MyException expected) {
    assertEquals("My exception message.", expected.getMessage());
  }
  verify(mockObj).someCleanup(eq(...));
}

Update: With Java 8's lambda expressions, you can wrap a functional interface call in a try block concisely enough to be useful. I imagine support for this syntax will find its way into many standard testing libraries.

assertThrows(MyException.class,
    () -> systemUnderTest.throwingMethod());

There is no real need for @Mock in Spock, because there is already = Mock(), which can be used everywhere an annotation can be used (and also in other places). There is an open pull request for @InjectMocks, but it hasn't been decided if such a feature will make it into spock-core or spock-guice. (Shipping this feature with spock-guice, or at least requiring Guice on the class path, would allow to delegate injection to Guice, rather than reinventing the wheel.) If not, @InjectMocks could always be shipped as a third-party Spock extension.

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.