How to use shouldShowExampleOfCorrectArgumentCapturing method of org.mockitousage.stacktrace.PointingStackTraceToActualInvocationTest class

Since java 8, the compiler type inference have been greatly improved.

Now you could remove the class parameter from the matcher without any compilation warning:

when(implClassMock.executeTask(any())).thenReturn(null);

Note: i have the same compiler failure but only with eclipse. A bug may be ?

The other answer is: fix your design instead of turning to the big PowerMock hammer.

Yes, PowerMock allows you to mock static methods. But you should understand: static is an abnormality in good OO design. You only use it when you have very good reasons. As it leads to tight coupling between your classes, and surprise: it breaks your ability to write reasonable unit tests. Yes, PowerMock works; but sometimes, it does not. When your classes grow, and you do more and more things "statically", because, you know, PowerMock will do the job ... be prepared for bizarre fails at some point, that can take hours to hunt down; without ever finding real bugs in your production code.

So, consider an alternative:

1. Do not use static method calls. And if there is some static method around that you can't touch; consider building a small interface around that.
2. Instead: use dependency injection and simply pass objects implementing some interface into your production code. Because you can mock such objects without the need for PowerMock(ito).

In that sense: you simply created hard to test code. Now you intend to fix that using PowerMock. The other way (much more reasonable in my eyes) is to learn how to write testable code in the first place. Here is a good starting point for that.

Take a look at the Mockito API docs. As the linked document mentions (Point # 12) you can use any of the doThrow(),doAnswer(),doNothing(),doReturn() family of methods from Mockito framework to mock void methods.

For example,

Mockito.doThrow(new Exception()).when(instance).methodName();

or if you want to combine it with follow-up behavior,

Mockito.doThrow(new Exception()).doNothing().when(instance).methodName();

Presuming that you are looking at mocking the setter setState(String s) in the class World below is the code uses doAnswer method to mock the setState.

World mockWorld = mock(World.class); 
doAnswer(new Answer<Void>() {
    public Void answer(InvocationOnMock invocation) {
      Object[] args = invocation.getArguments();
      System.out.println("called with arguments: " + Arrays.toString(args));
      return null;
    }
}).when(mockWorld).setState(anyString());

The two syntaxes for stubbing are roughly equivalent. However, you can always use doReturn/when for stubbing; but there are cases where you can't use when/thenReturn. Stubbing void methods is one such. Others include use with Mockito spies, and stubbing the same method more than once.

One thing that when/thenReturn gives you, that doReturn/when doesn't, is type-checking of the value that you're returning, at compile time. However, I believe this is of almost no value - if you've got the type wrong, you'll find out as soon as you run your test.

I strongly recommend only using doReturn/when. There is no point in learning two syntaxes when one will do.

You may wish to refer to my answer at Forming Mockito "grammars" - a more detailed answer to a very closely related question.

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.

You can do that:

doThrow(...).doNothing().when(mock).voidMethod();

(edit: use doNothing, as mentioned by @Rogério)

The code you posted works for me with the latest version of Mockito and Powermockito. Maybe you haven't prepared A? Try this:

A.java

public class A {
     private final String test;

    public A(String test) {
        this.test = test;
    }

    public String check() {
        return "checked " + this.test;
    }
}

MockA.java

import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.equalTo;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

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

@RunWith(PowerMockRunner.class)
@PrepareForTest(A.class)
public class MockA {
    @Test
    public void test_not_mocked() throws Throwable {
        assertThat(new A("random string").check(), equalTo("checked random string"));
    }
    @Test
    public void test_mocked() throws Throwable {
         A a = mock(A.class); 
         when(a.check()).thenReturn("test");
         PowerMockito.whenNew(A.class).withArguments(Mockito.anyString()).thenReturn(a);
         assertThat(new A("random string").check(), equalTo("test"));
    }
}

Both tests should pass with mockito 1.9.0, powermockito 1.4.12 and junit 4.8.2

As you noted, act is not a mock, and therefore you cannot record behavior on it. You could use Mockito.spy to, well, spy (or partially mock) the act object so that you only record the behavior of secondMethod and execute the actual code for firstMethod.

Note, however, that matchers can't be used in doReturn calls regardles of how you're mocking or spying your object. A return value must be a concrete object.

class ActivityTest() {

  Activity act;

  @Before
  public void setup(){
     act = Mockito.spy(new Activity()); // Here!
  }

  @Test
  public void testFirstMethod(){

      Mockito.doReturn("someString").when(act).secondMethod();
      act.firstMethod();
      verify(act).secondMethod();
  }
} 

A slightly more elegant syntax allows you to use annotations instead of explicitly calling Mockito.spy, but it's a matter of taste really:

@RunWith(MockitoJUnitRunner.class)
class ActivityTest() {

  @Spy
  Activity act = new Activity();

  @Test
  public void testFirstMethod(){

      Mockito.doReturn("someString").when(act).secondMethod();
      act.firstMethod();
      verify(act).secondMethod();
  }
} 

When you're using MockK you should not use Mockito.

Only using MockK you can achieve the same with:

val dal = mockk<UserDal> {
    every { insert(any()) } returnsArgument 0
}

If you intend to use Mockito, you should remove MockK and use mockito-kotlin:

val dal = mock<UserDal> {
    on { insert(any()) } doAnswer { it.arguments[0] }
}