How to use InvocationsFinder class of org.mockito.internal.invocation package

To verify a static method using Mockito -> MockedStatic.

If the method has parameters and you want to verify it then it will be verify by this way:

@Test
void testMethod() {
  try (MockedStatic<StaticProperties> theMock = Mockito.mockStatic(StaticProperties.class)) {
    theMock.when(StaticProperties.getProperty("abc", "xyz", "lmn"))).thenReturn("OK");

    //code .....

    theMock.verify(() -> StaticProperties.getProperty("abc", "xyz", "lmn"));
  }
  
}

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)

This could be achieved by PowerMockito framework.

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

@RunWith(PowerMockRunner.class)
@PrepareForTest(SomeClass.class)
public class SomeClassTest {

    private SomeClass someInstance;

    @Before
    public void setUp() throws Exception {

        someInstance = PowerMockito.spy(new SomeClass());
    }

    @Test
    public void sendRequest() throws Exception {

        String json = "JSON";
        String text = "Some text";
        int messageId = 1;

        PowerMockito.doReturn(true).when(someInstance, "isMethod");
        PowerMockito.doReturn(messageId).when(someInstance, "getMessageId", json);

        someInstance.sendRequest(json, text);

        PowerMockito.verifyPrivate(someInstance).invoke("isMethod");
        PowerMockito.verifyPrivate(someInstance).invoke("getMessageId", json);
        PowerMockito.verifyPrivate(someInstance).invoke("sendMessage", messageId, text);
    }

}

One of the problems with Mockito.when is that the argument you pass to it is the expression that you're trying to stub. So when you use Mockito.when twice for the same method call, the second time you use it, you'll actually get the behaviour that you stubbed the first time.

I actually recommend NOT using Mockito.when. There are many traps that you can fall into when you use it - quite a few cases when you need some other syntax instead. The "safer" alternative syntax is the "do" family of Mockito methods.

doReturn(value).when(mock).method(arguments ...);
doThrow(exception).when(mock).method(arguments ...);
doAnswer(answer).when(mock).method(arguments ...);

So in your case, you want

doThrow(new BadSqlGrammarException(??, ??, ??)).when(accountMapper).createBadGrammarException();

If you are starting out with Mockito, then I recommend that you learn to use the "do" family. They're the only way to mock void methods, and the Mockito documentation specifically mentions that. But they can be used whenever Mockito.when can be used. So if you use the "do" family, you'll end up with more consistency in your tests, and less of a learning curve.

For more information about the cases when you must use the "do" family, see my answer on Forming Mockito "grammars"

Try adding servlet-api dependency

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>3.1.0</version>
    <scope>provided</scope>
</dependency>

From what I read on "Issue 53" of mockito (https://code.google.com/p/mockito/issues/detail?id=53) , my code was experiencing a problem due to the validation framework involved in Mockito. Precisely the following code was causing the exception per se.

private ConstantNode getConstantNode(NumericalValue value){
    ConstantNode node = Mockito.mock(ConstantNode.class);
    Mockito.when(node.evaluate()).thenReturn(value);
    Mockito.when(node.toString()).thenReturn(value.toString());
    return node;
}

If you remember from my code, the parameter value is ALSO A MOCK, so that when value.toString() is called on the thenReturn(), I believe (and someone please correct me if I am wrong) that the validation framework is triggered and makes sure that every "when" has had its thenReturn() called/validated/etc. So that if this happenes, the Mockito.when(node.toString()).thenReturn(value.toString() will not be validated because it hasn´t returned from the valute.toString(), which started the whole "validate everything" chain.

How I fixed it:

private ConstantNode getConstantNode(NumericalValue value){
    ConstantNode node = Mockito.mock(ConstantNode.class);
    Mockito.when(node.evaluate()).thenReturn(value);

    String numberToString = value.toString();

    Mockito.when(node.toString()).thenReturn(numberToString);
    return node;
}

This way, it can be validated. I find this a complete code smell because I will literally have to leave a comment that explains why I am using a seemingly useless intermediate variable in the code.

Thanks for the help.

In short, you could use either one in most cases (especially in Java 8 or newer). any() is often more idiomatic to non-brittle Mockito tests, though there are some pragmatic reasons and some correctness reasons to use anyString or any(String.class). Beware: the full rationale delves deeply into Mockito matcher internals, Java type parameter inference, and a whole lot of hysterical raisins.

For primitives like anyFloat(), there is a very practical reason to prefer anyFloat() etc instead of any(): The latter will give you a NullPointerException. For Mockito syntax like when(floatAcceptor.acceptFloat(any())).then(/*...*/), Mockito will actually call your mocked floatAcceptor.acceptFloat(float) method, and calls to any() necessarily return null because Mockito matchers have to return a dummy value and Java doesn't tell Mockito enough for it to know to return a float-compatible value. Irrespective of Mockito, Java will try to unbox a null into a float and fail. (anyFloat() and any(Float.class) tell Mockito to expect a float, so they correctly return 0.0f.) If you know a value is a primitive, boxed or unboxed, it's safer to call the appropriate method. That reason goes away for List and String, which are objects through and through; Java will happily pass a null received from any.

Historically, any behaved identically to any(Class), anyString(), and anyList(Class); this was an important convenience, because Java 7 couldn't infer type arguments from parameters, so the alternative was (Foo) any() or ArgumentMatchers.<Foo>any(). Compared to those, any(Foo.class) is more readable. It gets even worse for Lists, because type literals don't support other types, so any(List.class) won't even work for List<Bar>; you'd need (List<Bar>) any(), or ArgumentMatchers.<List<Bar>>any(), but with anyList you can just write anyList(Bar.class) and be on your way. In all cases, the argument was entirely ignored, and to check types you'd need to use isA(Class) to do a reflective, null-rejecting, instanceof-style check.

However, two improvements happened that change this: Java 8 happily infers type arguments through parameters, so any() is much more usable, and Mockito corrected its syntax to appear more like English. In English, "any car" wouldn't likely include a bicycle or an empty parking spot, but in Mockito 1.x any(Car.class) would happily match invocations with a null or a Bicycle instance. Thus, in Mockito 2.x, any(String) and anyString() will only accept non-null Strings, as documented in GitHub issue #185. Same with all other any(Class) calls.

To top it all off, Mockito prefers flexible tests rather than brittle ones, so you are much more likely to see any() for an irrelevant Foo parameter than isA(Foo.class) or eq(new Foo()). Irrelevant parameters are ignored by convention, if changing them is unlikely to affect the behavior being tested. That said, anyString() and anyList() can be useful for readability when you know the argument isn't null, and can also help you keep track of long argument lists by failing to compile if your list changes in an incompatible way to the method you're calling.

So in summary: Use primitive methods for primitives, use any() as much as possible, but switch to any(Class), any(List), or any(String) if you want to check non-null types are correct, if you want to improve readability, or you need to maintain long frequently-changing argument lists.

You can read more on the semantics of any(), any(Class), and isA on this GitHub issues answer.

The parentheses are poorly placed.

You need to use:

doThrow(new Exception()).when(mockedObject).methodReturningVoid(...);
                                          ^

and NOT use:

doThrow(new Exception()).when(mockedObject.methodReturningVoid(...));
                                                                   ^

This is explained in the documentation

You should use thenReturn or doReturn when you know the return value at the time you mock a method call. This defined value is returned when you invoke the mocked method.

thenReturn(T value) Sets a return value to be returned when the method is called.

@Test
public void test_return() throws Exception {
    Dummy dummy = mock(Dummy.class);
    int returnValue = 5;

    // choose your preferred way
    when(dummy.stringLength("dummy")).thenReturn(returnValue);
    doReturn(returnValue).when(dummy).stringLength("dummy");
}

Answer is used when you need to do additional actions when a mocked method is invoked, e.g. when you need to compute the return value based on the parameters of this method call.

Use doAnswer() when you want to stub a void method with generic Answer.

Answer specifies an action that is executed and a return value that is returned when you interact with the mock.

@Test
public void test_answer() throws Exception {
    Dummy dummy = mock(Dummy.class);
    Answer<Integer> answer = new Answer<Integer>() {
        public Integer answer(InvocationOnMock invocation) throws Throwable {
            String string = invocation.getArgumentAt(0, String.class);
            return string.length() * 2;
        }
    };

    // choose your preferred way
    when(dummy.stringLength("dummy")).thenAnswer(answer);
    doAnswer(answer).when(dummy).stringLength("dummy");
}