How to use shouldFailWhenMethodCallsOnDifferentMocksAreOutOfSequence method of org.mockitousage.verification.BasicVerificationInOrderTest class

A better way to accomplish that would probably be:

when(someService.someMethod(id)).thenThrow(new AccountNotFoundException());

then the compiler should infer the type correctly.

If someService.someMethod(id) has return type void you can do:

doThrow(new AccountNotFoundException()).when(someService).someMethod(id);

Please refer to the official Mockito documentation for examples like this using thenThrow. The documentation is very clear on this point.

You can also check the following StackOverflow question which is very similar (if not an exact duplicate):

How to mock and assert a thrown exception

I think this happens because mockito doesn't know the semantic meaning of isEmpty() and when it encounters a boolean method mocks it with a default value that is false. Same think happens with size() but the default value here is 0.

Basically, you need to define the expected behaviour of your mocked object. If you don't, it will return default values.

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.

I've also wandered how to inject a mock into a spy.

The following approach will not work:

@Spy
@InjectMocks
private MySpy spy;

But the desired behavior can be achieved by a "hybrid" approach, when using both annotation and manual mocking. The following works perfectly:

@Mock
private NeedToBeMocked needToBeMocked;

@InjectMocks
private MySpy mySpy;

@InjectMocks
private SubjectUnderTest sut;

@BeforeMethod
public void setUp() {
    mySpy = Mockito.spy(new MySpy());
    MockitoAnnotations.initMocks(this);
}

(SubjectUnderTest here depends on MySpy, and MySpy in its turn depends on NeedToBeMocked).

UPD: Personally, I think that if you have to do such a magic too often, it might be a sign that there is something wrong with dependenicies between your classes and it is worth to perform a little bit of refactoring to improve your code.

There is no problem at all.

Let's examine these 4 lines of code:

IndexManager indexManager = mock(IndexManager.class);
when(graphDb.index()).thenReturn(indexManager);
when(indexManager.getNodeAutoIndexer()).thenReturn(nodeAutoIndexer);
when(graphDb.index().getRelationshipAutoIndexer()).thenReturn(relAutoIndexer);

The first line creates a mock indexManager.

The second one tells the mock graphDb to return indexManager (the mock created at first line) when the index method is called.

The third one telle the mock indexManager (created at first line) to return nodeAutoIndexer when its getNodeAutoIndexer method is called.

And the last line calls graphDb.index(), which returns the mock indexManager (you told it to do that at line two), and asks this indexManager (which is the mock you created at first line) to return relAutoIndexer when its getRelationshipAutoIndexer method is called.

The last line works only because you told the mock graphDb what to return when its index method is called. If you had not done this before, the mock graphDb.index() method would have returned null and you would have had an NPE.

It should be enough to name your mocks serviceA and serviceB. From Mockito documentation:

Property setter injection; mocks will first be resolved by type, then, if there is several property of the same type, by the match of the property name and the mock name.

In your example:

@InjectMocks ServiceCaller classUnderTest;

@Mock SomeService serviceA;
@Mock SomeService serviceB;

Note that it is not necessary to manually create class instance when using @InjectMocks.

Nevertheless I personally prefer injecting dependencies using constructor. It makes it easier to inject mocks in tests (just call a constructor with your mocks - without reflections tools or @InjectMocks (which is useful, but hides some aspects)). In addition using TDD it is clearly visible what dependencies are needed for the tested class and also IDE can generate your constructor stubs.

Spring Framework completely supports constructor injection:

@Bean
public class ServiceCaller {
    private final SomeService serviceA;
    private final SomeService serviceB;

    @Autowired
    public ServiceCaller(@Qualifier("serviceA") SomeService serviceA,
                         @Qualifier("serviceB") SomeService serviceB) { ... }

    ...
}

This code can be tested with:

@Mock SomeService serviceA;
@Mock SomeService serviceB;

//in a setup or test method
ServiceCaller classUnderTest = new ServiceCaller(serviceA, serviceB); 

If you follow the source code of jUnit. You will see that assertEquals eventually calls the equals method on the objects provided in the the isEquals method.

private static boolean isEquals(Object expected, Object actual) {
    return expected.equals(actual);
}

Source Code: https://github.com/junit-team/junit/blob/master/src/main/java/org/junit/Assert.java

This will call the .equals() method on the implementation of List. Here is the source code for the .equals() implementation of `ArrayList'.

ArrayList.equals()

  public boolean equals(Object o) {
      if (o == this) //Equality check
          return true;
      if (!(o instanceof List))  //Type check
          return false;
      ListIterator<E> e1 = listIterator();
      ListIterator e2 = ((List) o).listIterator();
      while(e1.hasNext() && e2.hasNext()) {
          E o1 = e1.next();
          Object o2 = e2.next();
          if (!(o1==null ? o2==null : o1.equals(o2))) //equality check of list contents
              return false;
      }
      return !(e1.hasNext() || e2.hasNext());
  }

Lenient mocks are what you want, if you can't just use a real UserKeychain.

Mockito.lenient().when(userKeychain.getUserStatus()).thenReturn(UserState.OK);
Mockito.lenient().when(otherUserKeychain.getUserStatus()).thenReturn(UserState.SUSPENDED);

Mockito is designed to replace systems where you can't use the real system in your test, particularly in systems that predictably invoke services instead of getting properties from data objects (or other idempotent actions). Because your system doesn't call those methods in a deterministic order, and because the calls aren't expensive and don't have side effects, I would recommend just going with the "lenient" option.

Imagine this case instead, where you are testing deleting user 1001:

when(userRpc.deleteUser(1001)).thenReturn(RPC_SUCCESS);
when(userRpc.deleteUser(1002)).thenReturn(RPC_SUCCESS);  // unnecessary

The test might pass if you ever delete the wrong user: Over-stubbing has masked a problem. Compare with this:

when(userRpc.fetchExpensiveUserDetails(1001)).thenReturn(user1001);
when(userRpc.fetchExpensiveUserDetails(1002)).thenReturn(user1002);  // unnecessary

Depending on what you're testing, this might be dangerous, but might not be so bad. Simulating a slow mobile network or with expensive data, maybe it is entirely against spec for you to fetch too much. However, in other cases, it may be acceptable. Finally, compare this case:

when(calculationResult.getRealComponent()).thenReturn(-1d);
when(calculationResult.getComplexComponent()).thenReturn(5);
when(calculationResult.getShortString()).thenReturn("-1 + 5i");

calculationResult looks an awful lot like a data object, and it is probably not a critical part of your test which of your methods to call or whether you're calling all of them. This is a case where Mockito's strict stubbing hinders you rather than helping you, and might be a case where you want to make some of those stubbings lenient. You might also choose to make the entire mock lenient, which particularly makes sense if you were to create a test helper method like stubCalculationResult(-1, 5) that prepared an entire object for you like that.

The only option better than that is to use a real object. In my example, if CalculationResult is an existing well-defined object, it may be lower risk overall to use a real one than to mock the behavior you believe at test-writing time to be correct. Similarly for your case, if you have access to a UserKeychain constructor that populates UserStatus etc, then it may be safer to use that in a test.

Though this might appear at first glance to be a slippery slope into turning a unit test into an integration test, I'd like to clarify that I'm recommending this only for data objects, which have no dependencies, and which ideally are immutable objects that have no methods with side-effects. If you use dependency injection, these are the type of single-implementation data holders that you would call new on rather than getting from your graph. This is also a good reason to separate your data objects so they are immutable and easy to construct, and to shift your services to consume those objects rather than giving methods to the data objects (favoring loginService.login(user) rather than user.login(loginService)).

I think the reason may be that mock object libraries typically create mocks by dynamically creating classes at runtime (using cglib). This means they either implement an interface at runtime (that's what EasyMock does if I'm not mistaken), or they inherit from the class to mock (that's what Mockito does if I'm not mistaken). Both approaches do not work for static members, since you can't override them using inheritance.

The only way to mock statics is to modify a class' byte code at runtime, which I suppose is a little more involved than inheritance.

That's my guess at it, for what it's worth...