How to use shouldNotVerifySkippedCallsWhenFewerCallsForMethodsOnDifferentMocks method of org.mockitousage.verification.BasicVerificationInOrderTest class

Spring uses commons-logging which auto-detects the logging framework to use. There are various ways to tune which logging framework will be chosen so the first thing to do is to make sure commons-logging binds to log4j.

To do that, start your application with an additional flag -Dorg.apache.commons.logging.diagnostics.dest=STDOUT that will output the result of the discovery process.

commons-logging delegate to log4j

You now need to make sure that log4j is initialise with the expected configuration. By default, log4j searches for a log4j.xml file at the root of the classpath and fallbacks to log4j.properties if it does not find one. It could be possible that one of the library you are using has (wrongly) a log4j.xml file at the root.

To debug log4j, run your application again with an additional flag -Dlog4j.debug=true. This will output the exact loggers and the location of the configuration file.

commons-logging does not delegate to log4j

If commons-logging does not delegate to log4j, this means that another logging framework is involved. The most common scenario is that your application ships with jcl-over-slf4j.jar, a drop-in replacement of commons-logging that uses slf4j behind the scene.

In this scenario, Spring uses commons-logging that is configured to delegate to slf4j. So, essentially, Spring is using slf4j. But slf4j is a simple logging facade and needs a binding to an actual framework.

SINCE 1.6.0 If no binding is found on the class path, then SLF4J will default to a no-operation implementation.

Once you have found the binding library (it could be logback or log4j for instance), check the configuration of the logging framework that slf4j is bound to.

In this particular case, you probably have logback in your classpath. As it is a pure implementation of slf4j, it does not need a binding library and it logs in debug if no configuration file is provided, which matches your problem actually. To fix your issue, exclude logback from your dependencies and add slf4j-log4j12 to configure slf4j with log4j.

Edit: updated with various comments

I don't know of other benefits offhand, but I want to address 2 of your sub-questions (and this is way too long for a comment):

allow mocking without dependency injection - this one isn't clear to me. Can you elaborate?

I think this came from the Motivation wiki page where they describe a way of refactoring code to not invoke static methods to make it testable. For a concrete example of what I think they're getting at, let's say you have this code and you want to test the method mocking the behaviour of the static method, without using powermock:

public class MyClass {
     public void doGetString() {
         ...
         OtherClass.getString(); //It's complex and scary and needs mocking!
         ...
     }
}

One solution, would be to pull the static invocation into its own object, then inject an object that can be mocked come test time. For example, without using other frameworks, this could look like:

public class MyClass {
     public static class StringGetter {
         public getString() {
             return OtherClass.getString();                 
         }
     }

     private final StringGetter getter;

     //Existing Constructor
     public MyClass() {
         this(new StringGetter());
     }

     //DI Constructor
     MyClass(StringGetter getter) {
         this.getter = getter;
     }

     public void doGetString() {
         ...
         getter.getString();
         ...
     }
}

I've seperated the behaviour of my method from the behaviour of the static invocation, and can use the DI constructor to inject mocks easily at test time. Of course with powermock I could just mock the static method in place, and run with it.

And do I need to sacrifice something when using PowerMock?

Physically no, but I'd say philosophically yes :). The below are my opinions, and I try to give good reasons behind them, but of course they are opinions so take them with a grain of salt:

The potentially scary thing that is happening with PowerMock is that in order to accomplish the feats of mocking private and static methods, they are using a custom class loader (which shouldn't be present at runtime in production) and changing the bytecode of your classes. Arguably, this should not matter with the vast majority of classes most of the time, but if you think about it, if the bytecode has changed, and certain side effects are no longer present, you're effectively testing different Classes albiet based upon your existing Classes. Yes this is a very academic argument.

You can somewhat mitigate this first argument by having good comprehensive integration and higher level tests that don't use PowerMock. In this way you can be more confident in the behaviours of your objects even if your unit tests are using PowerMock.

The other argument I have against PowerMock, is that it could almost too easily become a crutch. I agree that PowerMock can help with testing code that uses legacy code and other code that you do not have control over. However I would argue that when you have control over the classes that you need to mock, you should avoid its use. If you write a class with a private method or static method that you need to explicitly mock in order to test other methods, my gut instinct would say that this method may be doing too much and should be refactored and broken up. Having PowerMock already available in a project, you may be tempted to just mock it and move on, which would mitigate the pain that should encourage you to refactor the same. Yes there are sometimes due to various technical and non-technical constraints this is not possible, but it's good to solve pain points instead of avoid them :)

First thing, you should be passing spy in as the constructor argument.

That aside, here's how you could do it.

public class ResultCaptor<T> implements Answer {
    private T result = null;
    public T getResult() {
        return result;
    }

    @Override
    public T answer(InvocationOnMock invocationOnMock) throws Throwable {
        result = (T) invocationOnMock.callRealMethod();
        return result;
    }
}

Intended usage:

RealFactory factory     = new RealFactory();
RealFactory spy         = spy(factory);
TestedClass testedClass = new TestedClass(spy);

// At this point I would like to get a reference to the object created
// and returned by the factory.


// let's capture the return values from spy.create()
ResultCaptor<RealThing> resultCaptor = new ResultCaptor<>();
doAnswer(resultCaptor).when(spy).create();

// do something that will trigger a call to the factory
testedClass.doSomething();

// validate the return object
assertThat(resultCaptor.getResult())
        .isNotNull()
        .isInstanceOf(RealThing.class);

This question is ancient, but Mockito v2.1.0+ now has a built-in feature for this.

verify(mock, description("This will print on failure")).someMethod("some arg");

More examples included from @Lambart's comment below:

verify(mock, times(10).description("This will print if the method isn't called 10 times")).someMethod("some arg");
verify(mock, never().description("This will print if someMethod is ever called")).someMethod("some arg");
verify(mock, atLeastOnce().description("This will print if someMethod is never called with any argument")).someMethod(anyString());

I would try any(byte[].class)

I was intrigued by this post and the comments left by @David so I decided to code a working example for those who follow like me

/*
 * class to test
 */
public class A {

    public void methodA(String str) {
        this.methodB(str);
    }

    protected void methodB(String str) {
        // some implementation
    }
}

We want to assert that the value being passed into methodB() is what we expect. Reading up on the ArgumentCaptor led me to discover the equivalent Captor Annotation

import static org.junit.Assert.assertEquals;
import static org.mockito.Mockito.verify;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.ArgumentCaptor;
import org.mockito.Captor;
import org.mockito.Spy;
import org.mockito.runners.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class MultipleMethodCallTest {

    @Spy
    A a = new A();

    @Captor ArgumentCaptor<String> captor;

    @Test
    public void captureSecondMethodCallArgument() throws Exception {

        // EXPECTED

        String greeting = "hello world";

        // PERFORM TEST

        a.methodA(greeting);

        // ASSERT

        verify(a).methodB(captor.capture());

        assertEquals(greeting, captor.getValue());
    }
}

This example was tested with

• mockito-all-1.8.5.jar
• junit-4.8.2.jar

As I can see from your dependencies you are using the Jack$Jill compiler of android studio to use lambda expressions. I would rather suggest using retrolambda. You can checkout this post for more info on how to configure from this link.

Benifits of retrolambda:

You can use it also with build tool version bellow than 24.0.0 which is not the case with jack compiler.

And as suggested above this issue seems fixed in retrolambda.

Try:

verify(someService).process(ArgumentMatchers.<Collection<Person>>any());

Actually, IntelliJ automatically suggested this fix when I typed any()... Unfortunately you cannot use static import in this case.

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());