How to use settingsFor method of org.mockito.internal.creation.bytebuddy.AbstractByteBuddyMockMakerTest class

Use one, or more, ArgumentCaptors.

It is unclear what your types are here, but anyway. Let's suppose you have a mock which has a method doSomething() taking a Foo as an argument, then you do this:

final ArgumentCaptor<Foo> captor = ArgumentCaptor.forClass(Foo.class);

verify(mock).doSomething(captor.capture());

final Foo argument = captor.getValue();

// Test the argument

Also, it looks like your method returns void and you don't want it to do anything. Just write this:

doNothing().when(theMock).doSomething(any());

It is very likely that the Runnable hasn't been executed yet by the asyncTaskExecutor when you verify the invocation, resulting in a verification error in your unit test.

The best way to fix this is to join on the generated thread and wait for execution before verifying the invocations.

If you cannot get the instance of the thread, a possible work around is to mock the asyncTaskExecutor and implement it so it will execute the runnable directly.

private ExecutorService executor;

@Before
public void setup() {
    executor = mock(ExecutorService.class);
    implementAsDirectExecutor(executor);
}

protected void implementAsDirectExecutor(ExecutorService executor) {
    doAnswer(new Answer<Object>() {
        public Object answer(InvocationOnMock invocation) throws Exception {
            ((Runnable) invocation.getArguments()[0]).run();
            return null;
        }
    }).when(executor).submit(any(Runnable.class));
}

The message is pretty obvious: You can't mock non-visible and final classes. Short answer : Create a named class of your anonymous one, and test this class instead!

Long answer, let's dig why !

An anonymous class is final

You instantiate an anonymous class of FilterFactory, when the compiler sees an anonymous class, it creates a final and package visible class. So the anonymous class is not mockable through standard mean i.e. through Mockito.

Mocking anonymous class : possible but BRITTLE if not HACKY

OK, now suppose you want to be able to mock this anonymous class through Powermock. Current compilers compile anonymous class with following scheme :

Declaring class + $ + <order of declaration starting with 1>

Mocking anonymous class possible but brittle (And I mean it) So supposing the anonymous class is the eleventh to be declared, it will appear as

InputHelper$11.class

So you could potentially prepare for test the anonymous class:

@RunWith(PowerMockRunner.class)
@PrepareForTest({InputHelper$11.class})
public class InputHelperTest {
    @Test
    public void anonymous_class_mocking works() throws Throwable {
        PowerMockito.spy(InputHelper.BZIP2_FACTORY);  // This line fails
    }
}

This code will compile, BUT will eventually be reported as an error with your IDE. The IDE probably doesn't know about InputHelper$11.class. IntelliJ who doesn't use compiled class to check the code report so.

Also the fact that the anonymous class naming actually depends on the order of the declaration is a problem, when someone adds another anonymous class before, the numbering could change. Anonymous classes are made to stay anonymous, what if the compiler guys decide one day to use letters or even random identifiers!

So mocking anonymous classes through Powermock is possible but brittle, don't ever do that in a real project!

EDITED NOTE : The Eclipse compiler has a different numbering scheme, it always uses a 3 digit number :

Declaring class + $ + <pad with 0> + <order of declaration starting with 1>

Also I don't think the JLS clearly specify how the compilers should name anonymous classes.

You don't reassign the spy to the static field

PowerMockito.spy(InputHelper.BZIP2_FACTORY);  // This line fails
whenNew(BufferedInputStream.class).withArguments(in).thenReturn(buffer);
whenNew(CBZip2InputStream.class).withArguments(buffer).thenReturn(expected);
InputStream observed = InputHelper.BZIP2_FACTORY.makeFilter(in);

PowerMockito.spy returns the spy, it doesn't change the value of InputHelper.BZIP2_FACTORY. So you would need to actually set via reflection this field. You can use the Whiteboxutility that Powermock provide.

Conclusion

Too much trouble to just test with mocks that the anonymous filter uses a BufferedInputStream.

Alternative

I would rather write the following code:

An input helper that will use the named class, I don't use the interface name to make clear to the user what is the intent of this filter!

public class InputHelper {
    public static final BufferedBZIP2FilterFactory BZIP2_FACTORY = new BufferedBZIP2FilterFactory();
}

And now the filter itself :

public class BufferedBZIP2FilterFactory {
    public InputStream makeFilter(InputStream in) {
        BufferedInputStream buffer = new BufferedInputStream(in);
        return new CBZip2InputStream(buffer);
    }
}

Now you can write a test like this :

@RunWith(PowerMockRunner.class)
public class BufferedBZIP2FilterFactoryTest {

    @Test
    @PrepareForTest({BufferedBZIP2FilterFactory.class})
    public void wraps_InputStream_in_BufferedInputStream() throws Exception {
        whenNew(CBZip2InputStream.class).withArguments(isA(BufferedInputStream.class))
                .thenReturn(Mockito.mock(CBZip2InputStream.class));

        new BufferedBZIP2FilterFactory().makeFilter(anInputStream());

        verifyNew(CBZip2InputStream.class).withArguments(isA(BufferedInputStream.class));
    }

    private ByteArrayInputStream anInputStream() {
        return new ByteArrayInputStream(new byte[10]);
    }
}

But could eventually avoid powermock stuff for this test scenario if you force the CBZip2InputStream to only accept BufferedInputStream. Usually using Powermock means something is wrong with the design. In my opinion Powermock is great for legacy softwares, but can blind developers when designing new code; as they are missing the point of OOP's good part, I would even say they are designing legacy code.

Hope that helps !

The problem is that you are creating a mock of BaseManager but only BaseManagerImpl has a SessionFactory field. Mockito doesn't know about BaseManagerImpl. In your code you create two mocks which are completely independent of each other.

Unit tests are about testing an unit. So you should test BaseManagerImpl and RegistrationManagerImpl separately.

So you test BaseManagerImpl first:

public class BaseManagerImplTest {

    private BaseManagerImpl target;

    // ...
}

then you test RegistrationManagerImpl:

public class RegistrationManagerImplTest {

    private RegistrationManagerImpl target;

    // ...
}

I suggest that you should use the name target or something similar for your test target in your test class becaues it will make your code much more easier to read.

Another thing: If you test an object all of its dependencies should be mocked but you shouldn't care about the mocks' dependencies. You just mock their method invocations like:

Mockito.when(myMock.someMethod()).thenReturn(someResultObject);

Your brackets are in the wrong place, try this:

doNothing().when(mockRegistrationPeristImpl).create(any(Registration.class));

You don't need MockRestServiceServer object. The annotation is @InjectMocks not @Inject. Below is an example code that should work

@RunWith(MockitoJUnitRunner.class)
public class SomeServiceTest {
    @Mock
    private RestTemplate restTemplate;

    @InjectMocks
    private SomeService underTest;

    @Test
    public void testGetObjectAList() {
        ObjectA myobjectA = new ObjectA();
        //define the entity you want the exchange to return
        ResponseEntity<List<ObjectA>> myEntity = new ResponseEntity<List<ObjectA>>(HttpStatus.ACCEPTED);
        Mockito.when(restTemplate.exchange(
            Matchers.eq("/objects/get-objectA"),
            Matchers.eq(HttpMethod.POST),
            Matchers.<HttpEntity<List<ObjectA>>>any(),
            Matchers.<ParameterizedTypeReference<List<ObjectA>>>any())
        ).thenReturn(myEntity);

        List<ObjectA> res = underTest.getListofObjectsA();
        Assert.assertEquals(myobjectA, res.get(0));
    }

Updating my Android Studio to version 3.3 AND removing

testOptions {
    execution 'ANDROID_TEST_ORCHESTRATOR'
}

worked

This comes down to the implementation of the spy. According to the docs, the Spy is created as a copy of the real instance:

Mockito does not delegate calls to the passed real instance, instead it actually creates a copy of it. So if you keep the real instance and interact with it, don't expect the spied to be aware of those interaction and their effect on real instance state. The corollary is that when an unstubbed method is called on the spy but not on the real instance, you won't see any effects on the real instance.

It seems to be a shallow copy. As a result, as far as my debugging shows, the CacheLoader is shared between the copy and the original object, but its reference to its enclosing object is the original object, not the spy. Therefore the real retrieveValue is called instead of the mocked one.

I'm not sure offhand what the best way to resolve this would be. One way for this specific example would be to invert the CacheLoader dependency (i.e. pass it into Subject instead of Subject defining it internally), and mock that instead of Subject.

Something like this should do it (not tested):

doAnswer(new Answer() {
    public Object answer(InvocationOnMock invocation) {
        Object[] args = invocation.getArguments();
        List<?> list = (List<?>) args[0];
        list.clear();
        return null;
    }
}).when(test).clearList(any(List.class));