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

It looks like you both want to mock what happens when userService.getUserById() is called, and also verify that setPasswordChangeRequired(true) is called on that returned object.

You can accomplish this with something like:

UserService userService = mock(UserService.class);
User user = mock(User.class);
when(userService.getUserById(anyLong())).thenReturn(user);

...

// invoke the method being tested

...

verify(user).setPasswordChangeRequired(true);

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

In JUnit, Parameterized tests use a special runner that ensure that the test is instantiated multiple times, so each test method is called multiple times. Mockito is a tool for writing specific unit tests, so there is no built-in ability to run the same test multiple times with different Mockito expectations.

If you want your test conditions to change, your best bet is to do one of the following:

• Parameterize your test using JUnit, with a parameter for the mock inputs you want;
• Run a loop of different parameters in your test, which unfortunately avoids the "test one thing per method" philosophy
• Extract a method that actually performs the test, and create a new @Test method for each mock you want.

Note that there's no prohibition on using mock objects as @Parameterized test parameters. If you're looking to parameterize based on mocks, you can do that, possibly creating the mock and setting the expectations in a static method on the test.

Note about runners: This Parameterized test runner conflicts with Mockito's MockitoJUnitRunner: Each test class can only have one runner. You'll want to switch to @Before and @After methods or a Mockito JUnit4 rule for your setup, if you use them both.

As an example, compressed from a different answer that explains more about Parameterized runners versus JUnit rules and lifting from the JUnit4 Parameterized Test doc page and MockitoRule doc page:

@RunWith(Parameterized.class)
public class YourComponentTest {
    @Rule public MockitoRule rule = MockitoJUnit.rule();
    @Mock YourDep mockYourDep;

    @Parameters public static Collection<Object[]> data() { /* Return the values */ }

    public YourComponentTest(Parameter parameter) { /* Save the parameter to a field */ }

    @Test public void test() { /* Use the field value in assertions */ }
}

Your test is on methods, but it tests the whole class behavior. If your inner class is private then its an implementation detail. Something that the test shouldn't know. It there's a lot of behaviour in that inner-class and you want to test it independently maybe you should make it public and separate from this class.

Maybe you think: but then... it's a lot of code to test (a very big indivisible thing), can't I test something smaller? Well... yes. Test Driven Development mandates to make a minimal implementation and add more code only if you add more tests. So you start with some test and minimal implementation and evolve both of them until the tests have all the specification and the code all the implementation.

So don't worry about private inner classes. Test your class contract!

The problem is, you cannot mix argument matchers and real arguments in a mocked call. So, rather do this:

when(serviceValidatorStub.validate(
    any(),
    isA(UserCommentRequestValidator.class),
    eq(UserCommentResponse.class),
    eq(UserCommentError.class))
).thenReturn(new UserCommentResponse());

Notice the use of the eq() argument matcher for matching equality.

see: https://static.javadoc.io/org.mockito/mockito-core/1.10.19/org/mockito/Matchers.html#eq(T)

Also, you could use the same() argument matcher for Class<?> types - this matches same identity, like the == Java operator.

Inner static class configuration: When testing Spring components we usually use @RunWith(SpringJUnit4ClassRunner.class) and make our class @ContextConfiguration. By making class @ContextConfiguration you can create an inner static class for configuration and in it you have full control. There you define all you need as beans and @Autowired it in your test, along with dependencies which can be mocks or regular objects, depending on test case.

Component scanning production code: If there are more components needed for test you can add @ComponentScan but we try to make it scan only packages it needs (this is when you use @Component annotation but in your case you can add XML to @ContextConfiguration). This is a good choice when you do not need mocks and you have a complicated setup which needs to be production like. This is good for integration tests where you want to test how components interact with each other in functional slices you want to test.

Hybrid approach: This is the usual case when you have many beans which need to be production like but one or two need to be mocks. Then you can @ComponentScan production code but add an inner static class which is @Configuration and there define beans with annotation @Primary which will override production code configuration for that bean in case of tests. This is good since you do not need to write long @Configuration with all defined beans, you scan what you need and override what should be mocked.

In your case I would go with first approach like this:

package org.world.hello;

import static org.junit.Assert.*;
import org.mockito.Mockito;
import org.junit.Test;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class RoomTest {

    @Configuration
    //@ImportResource(value = {"path/to/resource.xml"}) if you need to load additional xml configuration
    static class TestConfig {
       @Bean
       public BottleCounter bottleCounter() {
        return Mockito.mock(BottleCounter.class);
       }

       @Bean
       public Room room(BottleCounter bottleCounter) {
         Room room = new Room();
         room.setBottleCounter(bottleCounter);
         //r.setNumBottles(3); if you need 3 in each test
         return room;           
       }
    }

    @Autowired
    private Room room;  //room defined in configuration with mocked bottlecounter

    @Test
    public void testThreeBottlesAreSeperatedByNewLines()
    {
        Mockito.when(b.countBottle(Mockito.anyInt())).thenReturn("a");
        r.setNumBottles(3);
        assertEquals("a\na\na\na\n", r.generatePoem());
    }

}

The reason why IsNonEmpty.matches() gets called on the second line of stubbing is that the Mockito.argThat(new IsEmpty()) returns null, which is then passed to mockHTable.get(). This call has to be checked against the earlier stubbing, to see whether it's a match; and that means calling IsNonEmpty.matches().

I'm not sure why this makes your test fail - it's hard to tell without seeing all of the code.

But, I would seriously recommend using doReturn...when instead of when...thenReturn whenever you have to stub the same mock more than once. You won't encounter issues like this if you do. In fact, I prefer to use doReturn...when in preference to when...thenReturn always (and similarly doThrow and doAnswer), although most people prefer when...thenReturn.

Re-writing one of your stubbing lines with the doReturn...when syntax looks like the following. The other is similar.

Mockito.doReturn(dbResult).when(mockHTable).get(Mockito.argThat(new IsNonEmpty()));  

Lastly, a plea, on behalf of the Mockito development team (of which I am a member). If you think there is a bug in Mockito here - and from your description, I think there may well be - please EITHER

• send a message to the Mockito mailing group (mockito@googlegroups.com) OR
• raise an issue on the Mockito issues list (http://code.google.com/p/mockito/issues/list).

It's useful to the Mockito team if you can actually post a complete example, rather than just what you think the key lines are - sometimes the cause of a Mockito problem is in quite an unexpected place.

You may want to try mockito. The test works like this:

You use mockito to "implement" EntityManager. Instead of the real code, you use the methods of mockito to say "if the application calls getReference(), then return this object". In the background, mockito will create a proxy instance which intercepts the Java method calls and returns the values which you specify. Calls to other methods will return null.

Mocking things like createQuery() works the same way but you first need to create a mockup of Query and then use the same approach as in getReference() (return the query mockup).

Since you don't use a real EM, you don't need a real persistence.xml.

A much more simple solution would be if you could set some property to change the name of the persistence.xml file but I don't think that this is possible.

Some other links that may help:

• How to configure JPA for testing in Maven
• Suggest a JPA Unit test framework

You need to do this.

when(userRepository.save(Mockito.any(User.class)))
                .thenAnswer(i -> i.getArguments()[0]);

And now you can obtain user which you pass as argument.