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

Is it poorly designed and implemented code to have a method that internally calls other methods?

Not really. But I'd say that, in this situation, the method that calls the others should be tested as if the others where not already tested separately. That is, it protects you from situations where your public methods stops calling the other ones without you noticing it.

Yes, it makes for (sometimes) a lot of test code. I believe that this is the point: the pain in writing the tests is a good clue that you might want to consider extracting those sub-methods into a separate class.

If I can live with those tests, then I consider that the sub-methods are not to be extracted yet.

What is the best practice and/or approach in writing a unit test for such a method (assuming it is itself a good idea) if one has chosen Mockito as their mocking framework?

I'd do something like that:

public class Blah {
    public int publicMethod() {
        return innerMethod();
    }

    int innerMethod() {
        return 0;
    }
}


public class BlahTest {
    @Test
    public void blah() throws Exception {
        Blah spy = spy(new Blah());
        doReturn(1).when(spy).innerMethod();

        assertThat(spy.publicMethod()).isEqualTo(1);
    }
}

As suggested

'disabling the Objenesis cache might help'

You can create override MockitoConfiguration.
To do so

• Create a package named org.mockito.configuration under your src/test/java
• Write the MockitoConfiguration class

Class File

package org.mockito.configuration;

public class MockitoConfiguration extends DefaultMockitoConfiguration {

  @Override
  public boolean enableClassCache() {
    return false;
  }
}

Try to build your code again.

Since I didn't get any response here I asked on the Mockito forums. Here is a link to the discussion: https://groups.google.com/d/topic/mockito/hWwcI5UHFi0/discussion

To summarize the answers, technically this would kind of defeat the purpose of mocking. You should really only mock the objects needed by the SystemUnderTest class. Mocking things within objects that are themselves mocks is kind of pointless.

If you really wanted to do it, @spy can help

From the link you posted;

Default answer of every Mockito mock.

• Returns appropriate primitive for primitive-returning methods
• Returns consistent values for primitive wrapper classes (e.g. int-returning method retuns 0 and Integer-returning method returns 0, too)
• Returns empty collection for collection-returning methods (works for most commonly used collection types)
• Returns description of mock for toString() method
• Returns null for everything else

From the FAQ:

What values do mocks return by default?

In order to be transparent and unobtrusive all Mockito mocks by default return 'nice' values. For example: zeros, falseys, empty collections or nulls.

It was probably done to stay consistent with any other methods which return null for any other non-collection, non-primitive Wrapper objects.

You can always implement your own Answer to pass to mock which returns empty strings for String returning methods.

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

The solution here is to use a customized answer. Two code samples: the first is the test classes used, the second is the test.

First, the test classes:

private interface Foo
{
    void bar(final List<String> list);
}

private static final class X
{
    private final Foo foo;

    X(final Foo foo)
    {
        this.foo = foo;
    }

    void invokeBar()
    {
        // Note: using Guava's Lists here
        final List<String> list = Lists.newArrayList("a", "b", "c");
        foo.bar(list);
        list.clear();
    }
}

On to the test:

@Test
@SuppressWarnings("unchecked")
public void fooBarIsInvoked()
{
    final Foo foo = mock(Foo.class);
    final X x = new X(foo);

    // This is to capture the arguments with which foo is invoked
    // FINAL IS NECESSARY: non final method variables cannot serve
    // in inner anonymous classes
    final List<String> captured = new ArrayList<String>();

    // Tell that when foo.bar() is invoked with any list, we want to swallow its
    // list elements into the "captured" list
    doAnswer(new Answer()
    {
        @Override
        public Object answer(final InvocationOnMock invocation)
            throws Throwable
        {
            final List<String> list
                = (List<String>) invocation.getArguments()[0];
            captured.addAll(list);
            return null;
        }
    }).when(foo).bar(anyList());

    // Invoke...
    x.invokeBar();

    // Test invocation...
    verify(foo).bar(anyList());

    // Test arguments: works!
    assertEquals(captured, Arrays.asList("a", "b", "c"));
}

Of course, being able to write such a test requires that you are able to inject into your "outer object" sufficient state so that the test is meaningful... Here it is relatively easy.

There a Spring test annotation (org.springframework.security.test.context.support.WithMockUser) which does this for you...

@Test
@WithMockUser(username = "myUser", roles = { "myAuthority" })
public void aTest(){
    // any usage of `Authentication` in this test invocation will get an instance with the user name "myUser" and a granted authority "myAuthority"
    // ...
}

Alternatively, you can continue with your current approach by mocking Spring's Authentication. For example, in your test case:

Authentication authentication = Mockito.mock(Authentication.class);

Then tell Spring's SecurityContextHolder to store this Authentication instance:

SecurityContext securityContext = Mockito.mock(SecurityContext.class);
Mockito.when(securityContext.getAuthentication()).thenReturn(auth);
SecurityContextHolder.setContext(securityContext);

Now, if your code needs Authentication to return something (the user name perhaps) you just set some expectations on the mocked Authentication instance in the usual way e.g.

Mockito.when(authentication.getName()).thenReturn("aName");

This is quite close to what you are already doing but you have just mocked the wrong type.

Update 1: in response to this update to the OP:

I now can get rid of the error in the testing class. I debugged into the code, see that the securityContext has value when I am in the testing class. But when I jump to the code inside the controller advice, the below get returns null:

SecurityContextHolder.getContext().getAuthentication().getPrincipal()

You just need to set an expectation on the mocked Authentication, for example:

UsernamePasswordAuthenticationToken principal = new UsernamePasswordAuthenticationToken("aUserName", "aPassword");
Mockito.when(authentication.getPrincipal()).thenReturn(principal);

With the above code this line ...

SecurityContextHolder.getContext().getAuthentication().getPrincipal();

... will return that UsernamePasswordAuthenticationToken.

Since you use a custom type (ApiKeyAuthentication, I think?) you should just let authentication.getPrincipal() return that type instead of a UsernamePasswordAuthenticationToken.

Use PowerMockito on top of Mockito.

Example code:

@RunWith(PowerMockRunner.class)
@PrepareForTest(DriverManager.class)
public class Mocker {

    @Test
    public void shouldVerifyParameters() throws Exception {

        //given
        PowerMockito.mockStatic(DriverManager.class);
        BDDMockito.given(DriverManager.getConnection(...)).willReturn(...);

        //when
        sut.execute(); // System Under Test (sut)

        //then
        PowerMockito.verifyStatic();
        DriverManager.getConnection(...);

    }

More information:

• Why doesn't Mockito mock static methods?

You can accomplish what you want with Mockito's argument matchers:

myObject.doSomeStuff();

verify(myMockedOtherObject, never()).someMethodOrOther(
    Mockito.anyString(),
    Mockito.anyString()
);

You can make that a little less verbose with a static import like you have for verify and never.