How to use inOrderRequiresFamiliarMock method of org.mockito.internal.exceptions.Reporter class

I would try any(byte[].class)

Mockito verifies the order across all the mocks that were passed to the inorder function. So if you don't want to verify the order of the foos you need to create two seperate in-orders. i.e.

@Test
public void testGroupOrder() {
    Foo foo1 = mock(Foo.class);
    Foo foo2 = mock(Foo.class);
    Bar underTest = new Bar();
    underTest.addFoo(foo1);
    underTest.addFoo(foo2);

    underTest.fire()

    InOrder inOrderFoo1 = inOrder(foo1);
    inOrderFoo1.verify(foo1).doThisFirst();
    inOrderFoo1.verify(foo1).beforeDoingThis();

    InOrder inOrderFoo2 = inOrder(foo2);
    inOrderFoo2.verify(foo2).doThisFirst();
    inOrderFoo2.verify(foo2).beforeDoingThis();
}

I would recommend approach #1, but would use Spring for dependency injection rather than instantiating DAOs directly.

This way, for unit testing the client code, you can substitue mock DAOs, and verify that the correct DAOs are invoked with the appropriate arguments. (Mockito is useful here.)

If you use static methods, then unit testing is much more difficult, since static methods cannot be overridden.

You can use a Mockito Spy for this. If you setup anotherObj as a spy you can verify method calls on that object. In your example you need to make sure that the call to foo uses the spy instead of an ordinary implementation of anotherObj. The spy is setup something like this:

AnotherClass anotherObjSpy = Mockito.spy(new AnotherClass());
// do stuff -- e.g. anotherObjSpy.foo(...);
verify(anotherObjSpy).codePath1(...);

(Slight disclaimer, I've never done this personally, just read about it in the javadoc)... If all of your methods on your mock interface would be ok with the same default behaviour, you could set the default answer on your mock in a manner like:

Foo myMock = Mockito.mock(Foo.class,new ThrowsExceptionClass(IllegalArgumentException.class));
Mockito.when(myMock.doSomething(Matchers.eq("1"))).thenReturn("1");

JavaDoc Links for: Mockito#mock and ThrowsExceptionClass

Alternatively, as is discussed in the Stubbing tutorial, order of the stubbing matters and last matching wins, so you might be able to also do:

Foo myMock = Mockito.mock(Foo.class);
Mockito.when(myMock.doSomething(Matchers.any(String.class))).thenThrow(IllegalArgumentException.class);
Mockito.when(myMock.doSomething(Matchers.eq("1"))).thenReturn("1");

For the service, it's good practice to either inject through the constructor or setter. This makes it easy to mock and pass in during unit testing. As for the mocking, you should use a framework like Mockito. Then you can do stuff like

MyService service = Mockito.mock(MyService.class);
when(service.getObject()).thenReturn(new Object());

HttpHeaders headers = Mockito.mock(HttpHeaders.class);
when(headers.getHeaderString("X-Header")).thenReturn("blah");

UriInfo uriInfo = Mockito.mock(UriInfo.class);
when(uriInfo.getRequestUri()).thenReturn(URI.create("http://localhost"));

Then you can just pass all these mocks to your resource class when UNIT testing.

For INTEGRATION testing you won't need to mock the headers or uriinfo. The actual ones will get passed in. But you can still mock the service if you want. Here's an example

public class MockServiceTest extends JerseyTest  {

    public static interface Service {
        String getMessage(String name);
    }

    @Path("message")
    public static class MessageResource {

        private final Service service;

        public MessageResource(Service service) {
            this.service = service;
        }

        @GET
        public String get(@QueryParam("name") String name,
                          @Context HttpHeaders headers,
                          @Context UriInfo uriInfo) {
            String nameQuery = uriInfo.getQueryParameters().getFirst("name");
            String header = headers.getHeaderString("X-Header");
            assertNotNull(nameQuery);
            assertNotNull(header);
            return service.getMessage(name);
        }
    }

    private Service service;

    @Override
    public ResourceConfig configure() {
        service = Mockito.mock(Service.class);
        return new ResourceConfig().register(new MessageResource(service));
    }

    @Test
    public void testIt() {
        Mockito.when(service.getMessage("peeskillet")).thenReturn("Hello peeskillet");

        Response response = target("message").queryParam("name", "peeskillet").request()
                .header("X-Header", "blah")
                .get();
        assertEquals(200, response.getStatus());
        assertEquals("Hello peeskillet", response.readEntity(String.class));
    }
}

The issue was resolved by adding the following code to the test class:

@Autowired
private WebApplicationContext context;

@Autowired
private Filter springSecurityFilterChain;

@Before
public void setup() {
    mockMvc = MockMvcBuilders.webAppContextSetup(context)
            .addFilters(springSecurityFilterChain).build();
}

As noted in another answer, if you don't care about the order, you might do best to change the interface so it doesn't care about the order.

If order matters in the code but not in a specific test, you can use the ArgumentCaptor as you did. It clutters the code a bit.

If this is something you might do in multiple tests, you might do better to use appropriate Mockito Matchers or Hamcrest Matchers, or roll your own (if you don't find one that fills the need). A hamcrest matcher might be best as it can be used in other contexts besides mockito.

For this example you could create a hamcrest matcher as follows:

import org.hamcrest.BaseMatcher;
import org.hamcrest.Description;
import org.hamcrest.Matcher;

import java.util.Collections;
import java.util.HashSet;
import java.util.List;
import java.util.Set;

public class MyMatchers {
    public  static <T> Matcher<List<T>> sameAsSet(final List<T> expectedList) {
        return new BaseMatcher<List<T>>(){
            @Override
            public boolean matches(Object o) {
                List<T> actualList = Collections.EMPTY_LIST;
                try {
                    actualList = (List<T>) o;
                }
                catch (ClassCastException e) {
                    return false;
                }
                Set<T> expectedSet = new HashSet<T>(expectedList);
                Set<T> actualSet = new HashSet<T>(actualList);
                return actualSet.equals(expectedSet);
            }

            @Override
            public void describeTo(Description description) {
                description.appendText("should contain all and only elements of ").appendValue(expectedList);
            }
        };
    }
}

And then the verify code becomes:

verify(mockClassB).sendEvent(argThat(MyMatchers.sameAsSet(expectedFileList)));

If you instead created a mockito matcher, you wouldn't need the argThat, which basically wraps a hamcrest matcher in a mockito matcher.

This moves the logic of sorting or converting to set out of your test and makes it reusable.

Mockito has an isNull matcher, where you can pass in the name of the class. So if you need to use it with other matchers, the correct thing to do is

verify(client).method(eq("String"),isNull(Class<?>.class));

This is now deprecated, see the answer below for the new method - https://stackoverflow.com/a/41250852/1348