How to use testDoubleArrayHiddenByObject method of org.mockito.internal.matchers.apachecommons.EqualsBuilderTest class

The method you are mocking is not accessible to the Mockito code.

Because your test code and your code under test are in the same package, the compiler lets you set up your mock that way, but at runtime, the Mockito library has to try to access moveAttachment, but it's not working in your case. This appears to be a bug or known limitation in Mockito as it should support that case, (and in fact, does support it in most cases).

The easiest thing to do would be to make moveAttachment a public method. If that is not an option, then first question whether you want to even mock it. What happens if the real method gets called?

The last option is to use PowerMock to treat the moveAttachment method as a private method and mock it that way.

I've never used Mockito, but want to learn, so here goes. If someone less clueless than me answers, try their answer first!

Mockito.when(reader.document(anyInt())).thenAnswer(new Answer() {
 public Object answer(InvocationOnMock invocation) {
     Object[] args = invocation.getArguments();
     Object mock = invocation.getMock();
     return document(fakeIndex((int)(Integer)args[0]));
     }
 });

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());

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 Mockito documentation repeatedly says it is often redundant. This appears verbatim both in verify(T)'s Javadoc as multiple single-line comments in the code block in Mockito's main class Javadoc section 2:

Although it is possible to verify a stubbed invocation, usually it's just redundant. If your code cares what get(0) returns, then something else breaks (often even before verify() gets executed). If your code doesn't care what get(0) returns, then it should not be stubbed. Not convinced? See here.

Note that the originally linked article, "Asking and Telling", was written by Mockito originator Szczepan Faber and can be considered an authoritative document in Mockito's design. To excerpt from that post:

Do I really have to repeat the same expression? After all, stubbed interactions are verified implicitly. The execution flow of my own code does it completely for free. Aaron Jensen also noticed that:

If you’re verifying you don’t need to stub unless of course that method returns something that is critical to the flow of your test (or code), in which case you don’t really need to verify, because the flow would have verified.

Just to recap: there is no repeated code.

But what if an interesting interaction shares the characteristic of both asking and telling? Do I have to repeat interactions in stub() and verify()? Will I end up with duplicated code? Not really. In practice: If I stub then it is verified for free, so I don’t verify. If I verify then I don’t care about the return value, so I don’t stub. Either way, I don’t repeat myself. In theory though, I can imagine a rare case where I do verify a stubbed interaction, for example to make sure the stubbed interaction happened exactly n times. But this is a different aspect of behavior and apparently an interesting one. Therefore I want to be explicit and I am perfectly happy to sacrifice one extra line of code…

Recent versions of Mockito (released since this Q&A was posted) have added some additional features that allow or default to stricter mocking styles. Despite this, the prevailing expectation is to avoid brittleness by only verifying what you can't confirm through assertions or successful test completion.

Overall, Mockito's design is to allow tests to be as flexible as possible, coding not to the implementation but instead to the spec of the method you're testing. Though you'll occasionally see a method call as part of a function's spec ("Submits an RPC to the server" or "Calls the passed LoginCallback immediately"), it's much more likely that you'll want to validate the postconditions that you can infer from the stubs: Checking that getFoo was called isn't really a part of the spec as long as you stubbed getFoo to return "foo" and the data store contains a single object with its corresponding property set to "foo".

In short, it is considered good Mockito style to explicitly verify only the interactions that can't be implied from well-crafted stubs and postcondition assertions. They may be good calls for otherwise-unmeasurable side effects—logging code, thread executors, ArgumentCaptors, multiple method calls, callback functions—but generally should not be applied to stubbed interactions.

Mockito provides regex matcher in standard org.mockito.Matchers class. Here is an example how this function can be used to verify invocation with proper parameter value:

verify(restMock, times(1)).exchange(matches(".*text=welcome.*to.*blah"), eq(HttpMethod.GET), any(ResponseEntity.class), eq(String.class));

I've recently adopted a project that uses JMockit and I think the quality of the code has certainly suffered as a result of the library's ability to mock out static and private methods.

The tests are very brittle because implementation details contained in private methods are being tested (so if I change how the class does something it can break tests, even if what the class does has not been affected).

The code is also littered with calls to static methods - if the developers had not had the ability to mock these out then I think they would have made more effort to de-couple things a little better.

Actually they are technically the same. When Mockito was first created, we were talking about stubs, so the vocabulary followed that idea. Later people thought it was better to think in interactions rather that technical terms, so the vocabulary followed the when ... then ... style. This change in vocabulary helps people to think about interactions, messaging between object. Which is the most interesting idea (message passing) thing in an object oriented language (quoting Alan Kay).

Nowadays testing approach has evolved to Behavior Driven Development (from Dan North), which is almost the same thing but focus even more on the behavior at design time. To reflect that thinking, people asked Mockito to offer an API that reflect that change. So you also use given ... will ... style from BDDMockito

given(the_type.performs_that()).willReturn(something)

This is my preferred vocabulary now as I use tests to drive my objects design.

You could also Stub Consecutive Calls (#10 in 2.8.9 api). In this case, you would use multiple thenReturn calls or one thenReturn call with multiple parameters (varargs).

import static org.junit.Assert.assertEquals;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

import org.junit.Before;
import org.junit.Test;

public class TestClass {

    private Foo mockFoo;

    @Before
    public void setup() {
        setupFoo();
    }

    @Test
    public void testFoo() {
        TestObject testObj = new TestObject(mockFoo);

        assertEquals(0, testObj.bar());
        assertEquals(1, testObj.bar());
        assertEquals(-1, testObj.bar());
        assertEquals(-1, testObj.bar());
    }

    private void setupFoo() {
        mockFoo = mock(Foo.class);

        when(mockFoo.someMethod())
            .thenReturn(0)
            .thenReturn(1)
            .thenReturn(-1); //any subsequent call will return -1

        // Or a bit shorter with varargs:
        when(mockFoo.someMethod())
            .thenReturn(0, 1, -1); //any subsequent call will return -1
    }
}