How to use ArrayEquals class of org.mockito.internal.matchers package

One of the problems with Mockito.when is that the argument you pass to it is the expression that you're trying to stub. So when you use Mockito.when twice for the same method call, the second time you use it, you'll actually get the behaviour that you stubbed the first time.

I actually recommend NOT using Mockito.when. There are many traps that you can fall into when you use it - quite a few cases when you need some other syntax instead. The "safer" alternative syntax is the "do" family of Mockito methods.

doReturn(value).when(mock).method(arguments ...);
doThrow(exception).when(mock).method(arguments ...);
doAnswer(answer).when(mock).method(arguments ...);

So in your case, you want

doThrow(new BadSqlGrammarException(??, ??, ??)).when(accountMapper).createBadGrammarException();

If you are starting out with Mockito, then I recommend that you learn to use the "do" family. They're the only way to mock void methods, and the Mockito documentation specifically mentions that. But they can be used whenever Mockito.when can be used. So if you use the "do" family, you'll end up with more consistency in your tests, and less of a learning curve.

For more information about the cases when you must use the "do" family, see my answer on Forming Mockito "grammars"

One way is using reflection get rid of final modifier from the field and then replace the LOGGER field with Mocked one

public class Class1Test {
    @Test
    public void test() throws Exception {
        Logger logger = Mockito.mock(Logger.class);
        Mockito.when(logger.isInfoEnabled()).thenReturn(false);
        setFinalStatic(Class1.class.getDeclaredField("LOGGER"), logger);
        Class1 cls1 = new Class1();
        assertFalse(cls1.demoMethod());
    }

    static void setFinalStatic(Field field, Object newValue) throws Exception {
        field.setAccessible(true);        
        Field modifiersField = Field.class.getDeclaredField("modifiers");
        modifiersField.setAccessible(true);
        modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL);
        field.set(null, newValue);
    }
}

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...

You are only asking Mockito to call the real thing on clear, the underlying object is still a fake created by Mockito for you. If you need a real LinkedList then just use the LinkedList - only the most heated purist of BDD would tell you to mock everything around you. I mean, you are not mocking Strings are you?

Mockito author himself has said that calling the real thing should be used scarcely, usually only for testing a legacy code.

If you need to spy on the real object (track the invocations) then Mockito has a feature for this too:

List list = new LinkedList();
List spy = spy(list);

With spy, you can still stub a method if you need. It basically works like a mock, but isn't ;)

I believe the output from above is I null {} because @InjectMocks field injection cannot correctly resolve the types since they are both of type Map. Is this correct?

Yes, correct on these field Mockito cannot clear the ambiguity, so it simply ignores these ambiguous fields.

With a very simple Mockito run JUnit test and class I am seeing different output when the test is run with Java 1.6.0_32 and Java 1.7.0_04 and want to understand why this is happening.

Actually the diferrence resides in a different behavior of Arrays.sort and hence Collections.sort() between JDK 6 and JDK 7. The difference resides in the new algorythm that should perform 20% less swaps. That's probably this swap operation that made things work under JDK6 and JDK7.

If I may you are "looking for trouble" if you rename only one mock field of the fields that have the same type (or same erasure). When mocks cannot be differentiated by type you really should name all your mock field to corresponding field, but the Javadoc does not state that clearly.

Thanks a lot for reporting that odd behavior by the way, I created an issue on Mockito, however for now I won't really solve this issue, but rather ensure the same behavior across JDKs. Solving this situation might need to code a new algorythm while maintaining compatibility, in the mean time you should name all your field mocks accordingly to the fields of tested class.

For now the thing to do will probably be tweaking the comparator with additional comparisons to enforce the same order on JDK6 and JDK7. Plus adding some warning in the Javadoc.

EDIT : Making two passes might solve the problem for most people.

Hope that helps. Thx for spotting the issue.

Also by the way you need either MockitoAnnotations.initMocks(this); or the runner @RunWith(MockitoJUnitRunner.class), using both is not necessary, and might even cause some problems. :)

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!

It seems Mockito gets confused when you call your deep stub in then when method. I was able to work around it by calling mock.getBar() separately:

    Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);
    Bar bar = mock.getBar();
    doReturn("deep").when(bar).getName();

I would try any(byte[].class)

verify(serviceMock, times(1)).serviceA();
verifyNoMoreInteractions(serviceMock);

From Mockito's javadoc on verifyNoMoreInteractions:

You can use this method after you verified your mocks - to make sure that nothing else was invoked on your mocks.

Also:

A word of warning: Some users who did a lot of classic, expect-run-verify mocking tend to use verifyNoMoreInteractions() very often, even in every test method. verifyNoMoreInteractions() is not recommended to use in every test method. verifyNoMoreInteractions() is a handy assertion from the interaction testing toolkit. Use it only when it's relevant. Abusing it leads to overspecified, less maintainable tests.