How to use verify_no_more_interactions method of org.mockito.InvocationFactoryTest 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);

They both achieve the same result. Using an annotation (@Mock) is usually considered "cleaner", as you don't fill up your code with boilerplate assignments that all look the same.

Note that in order to use the @Mock annotation, your test class should be annotated with @RunWith(MockitoJUnitRunner.class) or contain a call to MockitoAnnotations.initMocks(this) in its @Before method.

You seem to be after contradictory goals. On the one hand, you're trying to avoid writing data to disk, which isn't a bad goal in tests. On the other, you're trying to test your I/O-handling class, which means you'll be working with system utilities that assume that your File will work with native calls. As such, here's my guidance:

• Don't try to mock a File. Just don't. Too many native things depend on it.
• If you can, split your I/O-handling code into the half that opens a File and turns it into a Reader, and the half that parses HTML out of the Reader.
• At that point, you don't need a mock at all--just construct a StringReader to simulate the data source.
• While that handles your unit tests pretty well, you may also want to write an integration test that uses a temporary file and ensure that it reads right. (Thanks Brice for adding that tip!)

Don't be afraid to refactor your class to make testing easier, as here:

class YourClass {
  public int method(File file) {
    // do everything here, which is why it requires a mock
  }   
}   

class YourRefactoredClass {
  public int method(File file) {
    return methodForTest(file.getName(), file.isFile(),
        file.isAbsolute(), new FileReader(file));
  }   

  /** For testing only. */
  int methodForTest(
      String name, boolean isFile, boolean isAbsolute, Reader fileContents) {
    // actually do the calculation here
  }   
}   

class YourTest {
  @Test public int methodShouldParseBadHtml() {
    YourRefactoredClass yrc = new YourRefactoredClass();
    assertEquals(42, yrc.methodForTest(
        "bad.html", true, false, new StringReader(badHTMLText));
  }   
}   

At this point the logic in method is so straightforward it's not worth testing, and the logic in methodForTest is so easy to access that you can test it heavily.

I think it should be

verify(mockBar, times(2)).doSomething(...)

Sample from mockito javadoc:

ArgumentCaptor<Person> peopleCaptor = ArgumentCaptor.forClass(Person.class);
verify(mock, times(2)).doSomething(peopleCaptor.capture());

List<Person> capturedPeople = peopleCaptor.getAllValues();
assertEquals("John", capturedPeople.get(0).getName());
assertEquals("Jane", capturedPeople.get(1).getName());

You are chaining method calls on your mocked instance:

@Mock
HttpServletRequest mockedRequest = mock(HttpServletRequest.class);

First of all, you do not need to do both, either use the @Mock annotation or the mock method. Like this, you first assign a Mock and then replace this instance with another mock. I recommend the annotation as it adds some context to the mock such as the field's name. This might already cause your NullPointerException as you however never activate the annotations by calling:

MockitoAnnotations.initMocks(this);

as you do not consequently mock all instances with both measures so far. However, even doing so will further result in your exception, so let's move ahead.

Within friendWebService.createFriendRequest(mockedRequest) you call:

User user = (User) request.getSession().getAttribute("user");
User otherUser = (User) request.getSession().getAttribute("profileuser");

where you call a method on two mocks for which you did not specify any behavior. These mocks do by default return null. You need to specify behavior for this such as:

when(request.getSession()).thenReturn(myMockedSession);

before performing this chained call. Based on this, you can then specify how to react to calls on this mocked instance such as returning your user mocks.

You can write your custom matcher that will pass this condition.

 class NotNullObjects extends ArgumentMatcher<Review> {
     public boolean matches(Object object) {
         return object!=null;
     }
 }

Then usage

when(reviewBuilder.saveReviewModel(argThat(new NotNullObjects()))).thenReturn(2L);

My one advice is to think of some interface that you can expect there as na input of your method.

The correct invocation is:

doReturn(...).when(whatever).theMethod()

And not .when(whatever.theMethod()).

Mockito mock works when we mock the objects loosely.

Here is the change i have made to make it work:

when(controlWfDefTypeService.getDqCntlWfDefnTypCd(any(DqCntlWfDefn.class))
    .thenReturn(dqCntlWfDefnTyp);

Instead of passing the object of the Mock class, I passed the class with the Matcher any() and it works.

Instead of mocking you can create a dummy ResourceBundle implementation, and then pass it as an argument to .thenReturn(resourceBundle):

    import java.util.ResourceBundle;

    ResourceBundle dummyResourceBundle = new ResourceBundle() {
        @Override
        protected Object handleGetObject(String key) {
            return "fake_translated_value";
        }

        @Override
        public Enumeration<String> getKeys() {
            return Collections.emptyEnumeration();
        }
    };

    // Example usage
    when(request.getResourceBundle(any(Locale.class))).thenReturn(dummyResourceBundle)

If you need the actual keys and values, then you'll need to provide an implementation for getKeys(), e.g. a hashmap for storage and key lookup.