How to use should_allow_chained_stubbing_with_exception_class method of org.mockitousage.stubbing.StubbingWithThrowablesTest class

You either have to specify no matchers, or all the arguments need matches. So this:

when(userSubModuleDao.findById((any(UserSubModuleId.class)),false))

should be:

when(userSubModuleDao.findById(any(UserSubModuleId.class), eq(false)))

(I've removed the redundant brackets from around the any call.)

From the Matchers documentation:

Warning:

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

According tho the Mockito documentation for Spy,

Spying on real objects is often associated with "partial mocking" concept. However, Mockito spies are not partial mocks. Mockito spy is meant to help testing other classes - not the spy itself. Therefore spy will not help if you intend to verify if method calls other method on the same object. In this case I suggest being OO/SRPy (for example you might extract new class/interface...)

The OO refers to object-oriented, and SRP refers to Single responsibility principle. It is a design pattern that states the class should have one and only one responsibility, and in this case it you would tend to write code that doesn't need to test if internal methods are called.

http://en.wikipedia.org/wiki/Single_responsibility_principle

I would do this in one of the following ways:

1. Inject the key.
2. Stub the method call and set the key there.

Method 1 When I say inject the key I actually mean inject a KeyFactory. This means you can control the result within your test. For example:

KeyHolder newCode = injectedKeyFactory.getKeyHolder();
try {
    namedParameterJdbcTemplate.update(sql, paramMap, newCode);
} catch (DuplicateKeyException e) {
    logger.error("Duplicate Key");
}
data.setId(newCode.getKey().intValue());

Then in the test:

KeyHolder newCode = mock(KeyHolder.class);
Mockito.when(namedParameterJdbcTemplate.update(Mockito.anyString(), Mockito.any(MapSqlParameterSource.class), newCode)).thenReturn(1);
Mockito.when(newCode.getKey()).thenReturn(__preferredId__);

The key factory is a simple one which just returns a new GeneratedKeyHolder. It gets injected at construction time, so this method does assume you're using DI.

Method 2

Mockito.when(namedParameterJdbcTemplate.update(Mockito.anyString(), Mockito.any(MapSqlParameterSource.class), Mockito.any(GeneratedKeyHolder.class))).thenAnswer(new Answer() {
    Object answer(InvocationOnMock invocation) {
        Object[] args = invocation.getArguments();
        Map<String, Object> keyMap = new HashMap<String, Object>();
        keyMap.put("", __preferredId__);
        ((GeneratedKeyHolder)args[2]).getKeyList().add(keyMap);
    }
}).andReturn(1);

I've not really used Mockito, so sorry if the code's not quite right. :)

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.

Since Mockito 2.20 it is also possible, to add lenient() locally

@ExtendWith(MockitoExtension.class)
public class MockitoExample {

  static abstract class TestClass {
    public abstract int booleanMethod(boolean arg);
  }

  @Mock
  TestClass testClass;

  @BeforeEach
  public void beforeEach() {
    lenient().when(testClass.booleanMethod(eq(true))).thenReturn(1);
    lenient().when(testClass.booleanMethod(eq(false))).thenReturn(2);
  }

  @Test
  public void test() {
    assertEquals(1,testClass.booleanMethod(true));
    assertEquals(2,testClass.booleanMethod(false));
  }
}

Let me begin by saying you are on the right track by using Constructor Injection and not Field Injection(which makes writing tests with mocks much simpler).

public class MyServiceImplTest 
{
    private MyDataService myDataService;
    private NyService myService;

    @Mock
    private MyRepository myRepository;

    @Before
    public void setUp() {
        MockitoAnnotations.initMocks(this); // this is needed for inititalizytion of mocks, if you use @Mock 
        myDataService = new MyDataServiceImpl(myRepository);
        myService = new MyServiceImpl(myDataService);
    }

    @Test
    public void getById_ValidId() {

        doReturn(someMockData).when(myRepository).findOne("1");
        MyObject myObject = myService.getById("1");

        //Whatever asserts need to be done on the object myObject 
    }
}

The call goes all the way from your service --> dataService. But only your repository calls are mocked.
This way you can control and test all the other parts of your classes(both service and dataService) and mock only repository calls.

In the spirit of providing a possible solution (and contrary to my comments above) you could try one of the following

Option 1

If TestClass implements an interface you could achieve a similar test using andDelegateTo() as described in this post that talks about Easymock not supporting spying

Option 2

Remove your need for spying by extending the TestClass specifically for your testing requirements. This is a common approach to dealing with legacy code bases where you cannot alter the code under test.

I will use Mockito in this example so that it is aligned with your question, however the concept will work the same with Easymock.

public class TestClassUsingMockito {
    /**
    We extend the original class under test so that we can override the creation of IndexData and
    thereby remove the responsibility of creating this object from the @Test method
    */
    private class ClassForTesting extends TestClass {

        private Lock lock;
        private IndexData indexData;

        public ClassForTesting(IndexData indexData, Lock lock) {
            this.indexData = indexData;
            this.lock = lock;
        }

        @Override
        protected IndexData getIndex(InputClass input) {
            return indexData;
        }
    }

    /**
    Look Ma' no more Spys!
    */
    @Test
    public void testAddUsesWriteLock() {        
        // Prepare
        final Lock lock = Mockito.mock(Lock.class);
        final IndexData indexData = Mockito.mock(IndexData.class);
        Mockito.doReturn(lock).when(indexData).getWriteLock();
        // ... now use your new subclass for testing
        final TestClass objectUnderTest = new ClassForTesting(indexData, lock);
        final InputClass input = Mockito.mock(InputClass.class);

        // Invoke method under test
        objectUnderTest.add(input);

        // Verify
        Mockito.verify(indexData).getWriteLock();
        Mockito.verify(indexData, Mockito.never()).getReadLock();
        Mockito.verify(lock).lock();
        Mockito.verify(lock).unlock(); 
    }
}

What is the analogon of Mockito.spy/doReturn in EasyMock?

So having removed the need for a Spy() in your tests the Mockito call

Mockito.doReturn(lock).when(indexData).getWriteLock();

Can be written in EasyMock as

expect(indexData.getWriteLock()).andStubReturn(lock);

EasyMock example of the same Mockito test above

public class TestClassUsingEasymock extends EasyMockSupport {

    private class ClassForTesting extends TestClass {

        private Lock lock;
        private IndexData indexData;

        public ClassForTesting(IndexData indexData, Lock lock) {
            this.indexData = indexData;
            this.lock = lock;
        }

        @Override
        protected IndexData getIndex(InputClass input) {
            return indexData;
        }
    }


    @Test
    public void testAddUsesWriteLock() {
        // Prepare
        final Lock lock = createNiceMock(Lock.class);       
        final IndexData indexData = createNiceMock(IndexData.class);
        EasyMock.expect(indexData.getWriteLock()).andStubReturn(lock);

        // ... now use your new subclass for testing
        final TestClass objectUnderTest = new ClassForTesting(indexData, lock);
        final InputClass input = createNiceMock(InputClass.class);

        lock.lock();
        EasyMock.expectLastCall();

        lock.unlock();
        EasyMock.expectLastCall();

        replayAll();

        // Invoke method under test
        objectUnderTest.add(input);

        // Verify
        verifyAll();
    }
}

I fix this test using real object not mocked dto's

Mockito 2 now supports final classes and methods!

But for now that's an "incubating" feature. It requires some steps to activate it which are described in What's New in Mockito 2:

Mocking of final classes and methods is an incubating, opt-in feature. It uses a combination of Java agent instrumentation and subclassing in order to enable mockability of these types. As this works differently to our current mechanism and this one has different limitations and as we want to gather experience and user feedback, this feature had to be explicitly activated to be available ; it can be done via the mockito extension mechanism by creating the file src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker containing a single line:

mock-maker-inline

After you created this file, Mockito will automatically use this new engine and one can do :

 final class FinalClass {
   final String finalMethod() { return "something"; }
 }

 FinalClass concrete = new FinalClass(); 

 FinalClass mock = mock(FinalClass.class);
 given(mock.finalMethod()).willReturn("not anymore");

 assertThat(mock.finalMethod()).isNotEqualTo(concrete.finalMethod());

In subsequent milestones, the team will bring a programmatic way of using this feature. We will identify and provide support for all unmockable scenarios. Stay tuned and please let us know what you think of this feature!