How to use DefaultStackTraceCleaner class of org.mockito.internal.exceptions.stacktrace package

Building on @Alban's sleuthing in the comments, it looks like adding this annotation to your test case should circumvent the problem:

@PowerMockIgnore("com.smin.dummy.TestAnnotation")

It seems Mockito gets confused when you call your deep stub in then when method. I was able to work around it by calling mock.getBar() separately:

    Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);
    Bar bar = mock.getBar();
    doReturn("deep").when(bar).getName();

At first you should check your test logic. Usually there are 3 cases. First, you are mocking the wrong method (you made a typo or someone changed tested code so that mocked method is no longer used). Second, your test is failing before this method is called. Third, your logic falls in wrong if/switch branch somewhere in the code so that mocked method is not called.

If this is the first case you always want to change the mocked method for the one used in the code. With the second and the third it depends. Usually you should just delete this mock if it has no use. But sometimes there are certain cases in parametrized tests, which should take this different path or fail earlier. Then you can split this test into two or more separate ones but that's not always good looking. 3 test methods with possibly 3 arguments providers can make your test look unreadable. In that case for JUnit 4 you silent this exception with either

@RunWith(MockitoJUnitRunner.Silent.class) 

annotation or if you are using rule approach

@Rule
public MockitoRule rule = MockitoJUnit.rule().strictness(Strictness.LENIENT);

or (the same behaviour)

@Rule
public MockitoRule rule = MockitoJUnit.rule().silent();

For JUnit 5 tests you can silence this exception using this annotation provided in mockito-junit-jupiter package:

@ExtendWith(MockitoExtension.class)
@MockitoSettings(strictness = Strictness.LENIENT)
class JUnit5MockitoTest {
}

The necessary method is Mockito#verify:

public static <T> T verify(T mock,
                           VerificationMode mode)

mock is your mocked object and mode is the VerificationMode that describes how the mock should be verified. Possible modes are:

verify(mock, times(5)).someMethod("was called five times");
verify(mock, never()).someMethod("was never called");
verify(mock, atLeastOnce()).someMethod("was called at least once");
verify(mock, atLeast(2)).someMethod("was called at least twice");
verify(mock, atMost(3)).someMethod("was called at most 3 times");
verify(mock, atLeast(0)).someMethod("was called any number of times"); // useful with captors
verify(mock, only()).someMethod("no other method has been called on the mock");

You'll need these static imports from the Mockito class in order to use the verify method and these verification modes:

import static org.mockito.Mockito.atLeast;
import static org.mockito.Mockito.atLeastOnce;
import static org.mockito.Mockito.atMost;
import static org.mockito.Mockito.never;
import static org.mockito.Mockito.only;
import static org.mockito.Mockito.times;
import static org.mockito.Mockito.verify;

So in your case the correct syntax will be:

Mockito.verify(mock, times(4)).send()

This verifies that the method send was called 4 times on the mocked object. It will fail if it was called less or more than 4 times.

If you just want to check, if the method has been called once, then you don't need to pass a VerificationMode. A simple

verify(mock).someMethod("was called once");

would be enough. It internally uses verify(mock, times(1)).someMethod("was called once");.

It is possible to have multiple verification calls on the same mock to achieve a "between" verification. Mockito doesn't support something like this verify(mock, between(4,6)).someMethod("was called between 4 and 6 times");, but we can write

verify(mock, atLeast(4)).someMethod("was called at least four times ...");
verify(mock, atMost(6)).someMethod("... and not more than six times");

instead, to get the same behaviour. The bounds are included, so the test case is green when the method was called 4, 5 or 6 times.

This occurs because you are using any() along with a real parameter VehicleCollection.class of type Class<VehicleCollection>.

Change it just like below, and you should be fine:

 when(queryBus.handle(any(VehicleCollection.class), any(GetVehicle.class))).thenAnswer(null);

Mockito explains why:

If you are using argument matchers, all arguments have to be provided by matchers.

E.g: (example shows verification but the same applies to stubbing):

    // Correct - eq() is also an argument matcher
    verify(mock).someMethod(anyInt(), anyString(), eq("third argument"));


    // Incorrect - exception will be thrown because third argument is given without argument matcher.
    verify(mock).someMethod(anyInt(), anyString(), "third argument");    

I think it requires more custom work.

verify(row, new LastCall()).saveToDatabase();

and then

public class LastCall implements VerificationMode {
    public void verify(VerificationData data) {
        List<Invocation> invocations = data.getAllInvocations();
        InvocationMatcher matcher = data.getWanted();
        Invocation invocation = invocations.get(invocations.size() - 1);
        if (!matcher.matches(invocation)) throw new MockitoException("...");
    }
}

Previous Answer:

You are right. verifyNoMoreInteractions is what you need.

verify(row).setSomething(value);
verify(row).setSomethingElse(anotherValue);
verify(row).editABunchMoreStuff();
verify(row).saveToDatabase();
verifyNoMoreInteractions(row);

any() returns null. This choice was inevitable because the signature of any() is

public static <T> T any()

Since generic types are erased in Java, and since nothing is passed to the method that carries any type information (such as a Class<T>), null is the only reasonable return value.

This creates a problem if the method of the mock has an argument of primitive type because unboxing this null value throws a NullPointerException.

There are two possible solutions. You can either use the primitive versions (such as anyDouble()), or the version accepting a Class (e.g. any(Double.class)). In the latter case, since we are supplying type information to the method, it is possible to use this information to return a sensible non-null value (e.g. 0.0D in the case of double).

In this case do I need to write a captor for each argument in spite of the fact I need to capture only the first argument?

durron597's answer is correct—you do not need to capture all arguments if you want to capture one of them. One point of clarification, though: a call to ArgumentCaptor.capture() counts as a Mockito matcher, and in Mockito if you use a matcher for any method argument you do have to use a matcher for all arguments.

For a method yourMock.yourMethod(int, int, int) and an ArgumentCaptor<Integer> intCaptor:

/*  good: */  verify(yourMock).yourMethod(2, 3, 4);  // eq by default
/*  same: */  verify(yourMock).yourMethod(eq(2), eq(3), eq(4));

/*   BAD: */  verify(yourMock).yourMethod(intCaptor.capture(), 3, 4);
/* fixed: */  verify(yourMock).yourMethod(intCaptor.capture(), eq(3), eq(4));

These also work:

verify(yourMock).yourMethod(intCaptor.capture(), eq(5), otherIntCaptor.capture());
verify(yourMock).yourMethod(intCaptor.capture(), anyInt(), gt(9000));

Access MainConfig.xml directly. The src/test/resources directory contents are placed in the root of your CLASSPATH.

More precisely: contents of src/test/resources are copied into target/test-classes, so if you have the following project structure:

.
└── src
    └── test
        ├── java
        │   └── foo
        │       └── C.java
        └── resources
            ├── a.xml
            └── foo
                └── b.xml

It will result with the following test CLASSPATH contents:

• /foo/C.class
• /a.xml
• /foo/b.xml

To actually access the files from Java source, use getClass().getResource("/MainConfig.xml").getFile().